Codex Desktop automation thread resume fails when state_5.sqlite has blank model_provider despite JSONL session_meta provider

What version of the Codex App are you using?

Codex App with bundled CLI/runtime:

codex-cli 0.142.0-alpha.1
Codex Doctor v0.142.0-alpha.1 - macos-aarch64

codex doctor --summary after local repair reports:

15 ok - 1 idle - 4 notes - 1 warn - 1 fail
config loaded
databases healthy
rollout files and state DB thread inventory agree
websocket connected
active provider endpoints are reachable over HTTP

The remaining doctor failure is TERM=dumb from a non-interactive shell and appears unrelated.

What subscription do you have?

ChatGPT-authenticated Codex App account. Exact subscription tier is not included in local diagnostics.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex Desktop can fail to resume an automation-created local thread with this toast:

Codex can't load config.toml, so this thread can't resume.
Fix config.toml: Model provider `` not found.
After saving the file, reopen the thread.

This appears to be a stale/incomplete local thread-index row, not a bad config.toml.

The real rollout JSONL for the affected thread contains a non-empty provider:

"model_provider":"openai"

But the corresponding row in ~/.codex/state_5.sqlite had an empty provider:

id: 019edbe5-89a5-70d3-90e9-7c860472a6da
source: vscode
model: gpt-5.3-codex-spark
model_provider: ''
rollout_path: ~/.codex/sessions/2026/06/18/rollout-2026-06-18T14-01-53-019edbe5-89a5-70d3-90e9-7c860472a6da.jsonl

After manually updating that one row to model_provider='openai', the local inventory returned to a clean state and the provider error stopped:

blank provider rows: 0
rollout DB model providers openai=584

What steps can reproduce the bug?

I do not yet have a deterministic minimal repro, but I have hit the same failure class at least twice from Codex Desktop automation/worktree threads.

Current recurrence:

1. A cron automation created a worktree thread for a repo-local daily performance audit.
2. The saved transcript JSONL began with session_meta.payload.model_provider = "openai".
3. The threads row in ~/.codex/state_5.sqlite for that same thread had model_provider = ''.
4. Opening/resuming that thread in Codex Desktop failed with Model provider not found.
5. Repairing only the SQLite index row from the JSONL session metadata fixed the resume failure.

Relevant commands used locally:

sqlite3 ~/.codex/state_5.sqlite \
  "select id, source, thread_source, model, model_provider, rollout_path
   from threads
   where id='019edbe5-89a5-70d3-90e9-7c860472a6da';"

sqlite3 ~/.codex/state_5.sqlite.bak-20260619-provider-repair \
  "select id, source, thread_source, model, quote(model_provider), rollout_path
   from threads
   where id='019edbe5-89a5-70d3-90e9-7c860472a6da';"

rg -n '"model_provider"' \
  ~/.codex/sessions/2026/06/18/rollout-2026-06-18T14-01-53-019edbe5-89a5-70d3-90e9-7c860472a6da.jsonl

Evidence from the pre-repair DB backup:

019edbe5-89a5-70d3-90e9-7c860472a6da|vscode||gpt-5.3-codex-spark|''|~/.codex/sessions/2026/06/18/rollout-2026-06-18T14-01-53-019edbe5-89a5-70d3-90e9-7c860472a6da.jsonl

Evidence after repair:

019edbe5-89a5-70d3-90e9-7c860472a6da|vscode||gpt-5.3-codex-spark|openai|~/.codex/sessions/2026/06/18/rollout-2026-06-18T14-01-53-019edbe5-89a5-70d3-90e9-7c860472a6da.jsonl

Prior local occurrence:

Local logs show a previous repair of the same failure class:

Root found for real: app DB had empty provider.
Patched 3 rows where threads.model_provider = ''
Now all 3 rows have model_provider = 'openai'
Target fixed: 019ed6bf-827e-7fb1-95b9-6505a69907b2
model = gpt-5.3-codex-spark
model_provider = openai

This recurrence suggests the local index writer or reindexer can still create new blank-provider rows after previous rows have been repaired.

What is the expected behavior?

Codex should not persist or use a blank threads.model_provider value when the rollout session_meta has a valid provider.

Expected behavior:

• new automation/worktree threads should be indexed with model_provider='openai' when the transcript says model_provider='openai'
• resume should prefer or recover from the rollout JSONL provider when the SQLite index provider is blank
• codex doctor or startup reindex should detect and repair blank-provider rows from session metadata
• the UI error should not blame config.toml when config parses and the active provider is healthy

Additional information

The affected automation config itself appears valid and includes a model:

kind = "cron"
model = "gpt-5.3-codex-spark"
reasoning_effort = "medium"
execution_environment = "worktree"

The automation schema does not expose a provider field, so recreating the automation does not look like a durable fix.

Local workaround installed on my machine:

• a small guard script reads rows where threads.model_provider is blank
• for each row, it reads the corresponding rollout JSONL session_meta.payload.model_provider
• it updates only rows where the transcript has a non-empty provider
• a LaunchAgent runs that guard periodically

That workaround keeps the local sidebar/resume index usable, but the app should avoid creating the invalid index state in the first place.