Codex Desktop side chat can half-create without rollout, then resume/fork fails with thread-store Is a directory

[AndyWendt]

What version of Codex are you running?

Codex Desktop for macOS 26.429.30905 (2345)

App-server / CLI version observed in local thread metadata: 0.128.0-alpha.1

What platform is your computer?

• macOS 26.4.1 (25E253)
• Apple Silicon / arm64

What subscription do you have?

Pro

What issue are you seeing?

A side chat in Codex Desktop appears to have been half-created: it exists in the renderer/current UI and accepts some internal thread/inject_items / turn/start activity, but it is never persisted to state_5.sqlite and no rollout JSONL is written under ~/.codex/sessions. After that, trying to resume or fork from that side chat repeatedly fails with a toast:

Error creating task
failed to read thread: thread-store internal error: failed to read thread /Users/andywendt/.codex: Is a directory (os error 21)

Earlier, the parent chat itself also failed to resume with the same failed to read thread /Users/andywendt/.codex: Is a directory message until I manually restored the missing threads row in ~/.codex/state_5.sqlite from the existing rollout JSONL. The parent then opened again, but the right-hand side chat remained broken.

The important persisted-state mismatch for the broken side chat:

• Parent thread id: 019df0cd-d3f9-71a1-9009-c5cef1e161ab
• Parent rollout exists: ~/.codex/sessions/2026/05/03/rollout-2026-05-03T20-25-14-019df0cd-d3f9-71a1-9009-c5cef1e161ab.jsonl
• Broken side chat id: 019df0f2-d18e-7b02-8c91-38e76fbb5164
• No threads row exists for 019df0f2-d18e-7b02-8c91-38e76fbb5164
• No rollout file exists for 019df0f2-d18e-7b02-8c91-38e76fbb5164
• A second nearby side chat id, 019df0f3-0e28-7f82-9afd-b4f997d4306b, shows the same missing persisted state

Commands used to verify:

sqlite3 -header -column ~/.codex/state_5.sqlite "select id, title, cwd, rollout_path, datetime(updated_at,'unixepoch') as updated from threads where id in ('019df0cd-d3f9-71a1-9009-c5cef1e161ab','019df0f2-d18e-7b02-8c91-38e76fbb5164','019df0f3-0e28-7f82-9afd-b4f997d4306b');"
find ~/.codex/sessions ~/.codex/archived_sessions -type f -name '*019df0f2*' -o -name '*019df0f3*'

The sqlite3 query returns only the repaired parent row. The find command returns no files for either side-chat id.

Relevant log excerpts from ~/Library/Logs/com.openai.codex/2026/05/04/codex-desktop-d7d022b7-4d32-470e-b4cb-92bb8439f867-40966-t0-i1-022505-0.log:

2026-05-04T03:05:38.547Z error [electron-message-handler] Conversation state not found conversationId=019df0f2-d18e-7b02-8c91-38e76fbb5164
2026-05-04T03:05:38.565Z info [AppServerConnection] response_routed ... method=thread/inject_items ... conversationId=019df0f2-d18e-7b02-8c91-38e76fbb5164 ... errorCode=null
2026-05-04T03:05:45.862Z info [AppServerConnection] response_routed ... method=turn/start ... conversationId=019df0f2-d18e-7b02-8c91-38e76fbb5164 ... errorCode=null
2026-05-04T04:14:55.842Z error [electron-message-handler] Request failed conversationId=019df0f2-d18e-7b02-8c91-38e76fbb5164 ... method=thread/fork ... error={"code":-32600,"message":"no rollout found for thread id 019df0f2-d18e-7b02-8c91-38e76fbb5164"}
2026-05-04T04:18:01.470Z error [electron-message-handler] Request failed conversationId=019df0f2-d18e-7b02-8c91-38e76fbb5164 ... method=thread/resume ... error={"code":-32603,"message":"failed to read thread: thread-store internal error: failed to read thread /Users/andywendt/.codex: Is a directory (os error 21)"}

Steps to reproduce

I do not have a minimal deterministic repro yet, but this happened during normal Codex Desktop side-chat usage:

1. Open an existing Codex Desktop thread.
2. Start a side chat from that thread.
3. Run work in the side chat long enough that it receives thread/inject_items and turn/start events.
4. Later, try to resume the side chat or create a task/fork from it.
5. The app shows Error creating task or Failed to resume chat with failed to read thread /Users/<user>/.codex: Is a directory (os error 21).

Expected behavior

A side chat should be persisted atomically before the renderer can route turns to it. If persistence fails, the UI should not keep a side-chat tab that can later be resumed/forked but has no rollout path.

At minimum, thread/resume / thread/fork should fail with a direct missing-rollout or missing-thread-state error instead of falling back to reading ~/.codex as though it were a rollout file.

Additional context

The parent thread was recoverable because its rollout JSONL existed and only its threads row was missing. The side chat was not recoverable because neither the DB row nor the rollout file existed, even though app logs show it had received turns in the active UI.

[GP2P]

Adding another current macOS datapoint that appears related to this side-chat fork/resume path.

Environment:

• Codex Desktop for macOS 26.506.31421 (2620)
• Darwin 25.3.0 arm64

Observed behavior:

1. Open an existing Codex Desktop conversation.
2. Start a side chat from that conversation.
3. Use the Fork action from the side chat.
4. The app shows a Failed to fork chat toast instead of creating the fork.

I have not inspected local state/logs deeply enough to confirm the exact missing-rollout / thread-store Is a directory root cause from this report. The visible user-facing failure is the side-chat fork failure, still reproducible on the newer macOS build above. I am avoiding logs/thread IDs here because they may include private project or thread context, but can collect targeted non-sensitive diagnostics if maintainers specify what would help.

[sleepyy-dog]

Adding a Windows datapoint that appears closely related.

Environment:

• Codex Desktop for Windows, x64
• Installed app package observed locally as 26.506.3741.0

Observed behavior:

1. A Codex Desktop side conversation tab was left open/idle for a while.
2. Later, trying to create a task from that side conversation failed.
3. The visible error was:

Error creating task
failed to read thread: thread-store internal error: failed to read thread \\?\C:\Users\<redacted>\.codex: Access is denied. (os error 5)

This looks analogous to the macOS failed to read thread /Users/.../.codex: Is a directory (os error 21) case described above: the app/server appears to be trying to read the Codex home directory itself as if it were a thread/rollout file. On Windows, that manifests as Access is denied. (os error 5).

I have not inspected local DB rows or rollout files for this machine yet. Intentionally omitting thread IDs, exact usernames, project paths, and logs for privacy. The broken side tab no longer seems usable; opening a new side conversation/main thread appears to be the practical workaround.

[HRASTUDIO]

Confirming another matching case on Codex Desktop macOS.

Environment:

• Codex Desktop version observed locally: 26.513.20950
• macOS / Apple Silicon machine
• Chrome version: 148.0.7778.168
• Codex Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex Chrome extension version: 1.1.4

Observed impact:

• Side conversation/thread can appear usable in the UI.
• Later resume/fork behavior fails because the thread/session pointer is broken or missing.
• Local mitigation can back up sessions and help rescue transcripts, but it cannot fix the underlying app session persistence/resume/fork logic.

Why this appears to match this issue:

• The failure class is a half-created side chat/thread state: UI-visible work exists, but the persisted session/rollout state is not reliable enough for later resume/fork.
• This is consistent with the app needing to validate and persist side-chat/session state atomically before allowing turns, resume, or fork.

Expected fix:

• Persist side-chat/thread state atomically before the UI allows meaningful work in that side thread.
• If persistence fails, disable resume/fork for that side thread and show a clear recoverable error.
• Resume/fork should fail with a direct missing-session/missing-rollout error, not a broken filesystem pointer or stale thread-store path.

I am not attaching raw session files or database dumps because they may contain private project content, but redacted log excerpts and sanitized diagnostics can be provided if useful.