›_ Codex Issues
Codex Issues / #22001

Codex Desktop macOS: side chat receives turns but is not persisted, then Fork fails with no rollout found

Open 💬 7 comments Opened May 10, 2026 by GP2P
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop for macOS 26.506.31421 (2620)

What subscription do you have?

Pro

What platform is your computer?

  • Darwin 25.3.0
  • Apple Silicon / arm64

What issue are you seeing?

Forking a side chat in Codex Desktop for macOS fails with a Failed to fork chat toast. After checking local metadata and app logs, this looks like another instance of the side-chat persistence mismatch described in #20944, but on a newer macOS app build.

Related issues:

  • #20944
  • #20977

I am filing this separately because the visible failure here is immediate thread/fork failure from a side chat, and I was able to confirm the same local-state mismatch without dumping any message content.

For the failing side-chat conversation id 019e1071-83e9-72e3-b7c6-6abb38f9c282:

  • The app log first shows Conversation state not found for that id.
  • Immediately after, thread/inject_items succeeds for that same id.
  • Multiple later turn/start calls succeed for that same id.
  • The browser-use route is captured and later completed for that same id.
  • thread/unsubscribe succeeds for that same id.
  • Later, thread/fork fails three times for that same id with no rollout found for thread id ....
  • ~/.codex/state_5.sqlite has no row in threads for that id.
  • ~/.codex/state_5.sqlite has no matching parent or child row in thread_spawn_edges for that id.
  • ~/.codex/sessions/2026/05/10 has no rollout JSONL file matching that id.

So the side chat appears usable while it is active in the renderer, but it is never registered as a persisted thread and never gets a rollout file. Fork then calls thread/fork with that side-chat conversation id and fails because the app/server cannot find a rollout for it.

Steps to reproduce

I do not have a clean minimal repro yet, but this happened during normal Codex Desktop usage:

  1. Open an existing Codex Desktop conversation.
  2. Start a side chat from that conversation.
  3. Run work in the side chat.
  4. Use the Fork action from the side chat.
  5. The app shows Failed to fork chat.

Expected behavior

Either:

  • Side chats should be persisted before they can receive turns and before the Fork action is available, so thread/fork has a valid thread row and rollout path.

Or:

  • If side chats are intentionally ephemeral/non-forkable, the UI should not expose Fork for them and should explain that they cannot be promoted to regular chats.

Local evidence

Log excerpts from ~/Library/Logs/com.openai.codex/2026/05/10/...log, with no message content included:

2026-05-10T05:52:15.417Z error [electron-message-handler] Conversation state not found conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282
2026-05-10T05:52:15.420Z error [electron-message-handler] Conversation state not found conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282
2026-05-10T05:52:15.422Z info [AppServerConnection] response_routed ... conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... method=thread/inject_items ... errorCode=null
2026-05-10T05:52:29.569Z info [AppServerConnection] response_routed ... conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... method=turn/start ... errorCode=null
2026-05-10T06:15:49.193Z info [AppServerConnection] response_routed ... conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... method=turn/start ... errorCode=null
2026-05-10T06:40:13.546Z info [AppServerConnection] response_routed ... conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... method=turn/start ... errorCode=null
2026-05-10T06:52:15.432Z info [AppServerConnection] response_routed ... conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... method=thread/unsubscribe ... errorCode=null
2026-05-10T07:09:29.114Z info [AppServerConnection] response_routed ... conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... method=thread/fork ... errorCode=-32600
2026-05-10T07:09:29.115Z error [electron-message-handler] Request failed conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... error={"code":-32600,"message":"no rollout found for thread id 019e1071-83e9-72e3-b7c6-6abb38f9c282"} ... method=thread/fork
2026-05-10T07:09:33.839Z error [electron-message-handler] Request failed conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... error={"code":-32600,"message":"no rollout found for thread id 019e1071-83e9-72e3-b7c6-6abb38f9c282"} ... method=thread/fork
2026-05-10T07:09:34.602Z error [electron-message-handler] Request failed conversationId=019e1071-83e9-72e3-b7c6-6abb38f9c282 ... error={"code":-32600,"message":"no rollout found for thread id 019e1071-83e9-72e3-b7c6-6abb38f9c282"} ... method=thread/fork

Metadata checks:

sqlite3 ~/.codex/state_5.sqlite "SELECT COUNT(*) FROM threads WHERE id='019e1071-83e9-72e3-b7c6-6abb38f9c282';"
# 0

sqlite3 ~/.codex/state_5.sqlite "SELECT parent_thread_id, child_thread_id, status FROM thread_spawn_edges WHERE child_thread_id='019e1071-83e9-72e3-b7c6-6abb38f9c282' OR parent_thread_id='019e1071-83e9-72e3-b7c6-6abb38f9c282';"
# no rows

find ~/.codex/sessions/2026/05/10 -maxdepth 1 -name '*019e1071-83e9-72e3-b7c6-6abb38f9c282*' -print
# no files

I also saw several nearby Received turn/started for unknown conversation log entries for other conversation ids during the same app session, which may be related, but I have not traced those ids deeply.

Additional information

I avoided attaching full logs, database dumps, or rollout files because they can include private project/thread context. The excerpts above are limited to method names, timestamps, ids, and error messages.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #20944
  • #20977
  • #21583

Powered by Codex Action

GP2P · 3 months ago

Additional findings after digging through the app-server path:

  • /side starts from side_fork_config() and sets fork_config.ephemeral = true, so the side chat is loaded in ThreadManager but remains pathless and does not get a rollout file.
  • That explains the mixed behavior in the logs: the side chat can still receive thread/inject_items and turn/start, because those use the loaded thread, but thread/fork fails because it only tries to read persisted thread-store history.
  • For this repro, the failing thread id also had no matching state-db thread row, no spawn edge, and no local session file, so the no rollout found for thread id ... error is consistent with an unmaterialized ephemeral source rather than a missing file lookup for a normal persisted thread.

I tried a patch along this path: when thread/fork cannot find a rollout for a requested source id and the source thread is currently loaded/pathless/ephemeral, fall back to the loaded thread's in-memory response history and materialize the new promoted fork normally unless the caller requested ephemeral. The patch also preserves source metadata so the promoted fork keeps forked_from_id behavior aligned with normal persisted forks.

Focused verification passed:

  • git diff --check
  • cargo test -p codex-app-server live_thread_fork_history_is_resumed_without_rollout_path
  • cargo test -p codex-app-server thread_fork_can_promote_loaded_ephemeral_thread_without_rollout
  • cargo clippy -p codex-app-server --tests

Full cargo test -p codex-app-server was also run. The new thread_fork coverage passed, but this local run had 5 failures that look environment-specific: several tests failed because git commit signing went through 1Password in test-created repos, and one skills warning-count assertion differed from the locally installed skills set.

GP2P · 3 months ago

I also noticed the current contributing guide says external code contributions are by invitation only, and recommends sharing analysis, reproduction details, root-cause hypotheses, and a high-level fix outline directly in the issue first. So rather than asking for an unsolicited PR review, here is the proposed fix information in that format.

What

  • Teach thread/fork to recover when the requested source thread has no persisted rollout but is still loaded in the app-server.
  • This specifically covers pathless/ephemeral side-chat-like threads that can receive turns through the loaded ThreadManager instance but cannot currently be promoted/forked because the fork path only reads persisted thread-store history.
  • The proposed branch also adds a synthetic source SessionMeta item to the in-memory fork history so the materialized promoted fork can preserve forked_from_id behavior like normal persisted forks.

Why

  • The observed failure is not that the source thread is gone: the same id successfully handled thread/inject_items and turn/start first.
  • The failure occurs later when thread/fork asks the thread store for a rollout and gets no rollout found for thread id ....
  • /side appears to create exactly this kind of source by using side_fork_config() with fork_config.ephemeral = true, so the source can be live but pathless.

How

  • Keep the existing persisted-thread path unchanged for normal forks.
  • If read_stored_thread_for_resume(... include_history=true) fails with no rollout found and no explicit rollout path was supplied, look up the source id in ThreadManager.
  • Only use the live fallback for a loaded source that is ephemeral/pathless; clone its in-memory response history and pass it through the existing fork machinery as resumed history with rollout_path: None.
  • Let the destination fork materialize normally unless the caller requested ephemeral.

Patch branch/commit for reference, not as a request for unsolicited review:

Verification run locally

  • git diff --check
  • cargo test -p codex-app-server live_thread_fork_history_is_resumed_without_rollout_path
  • cargo test -p codex-app-server thread_fork_can_promote_loaded_ephemeral_thread_without_rollout
  • cargo clippy -p codex-app-server --tests

I also ran cargo test -p codex-app-server; the new thread_fork coverage passed, but this local full-package run had 5 apparent environment-specific failures: test-created git repos hit 1Password-backed commit-signing errors, and one skills warning-count assertion differed from the locally installed skills set.

andrew05060414 · 1 month ago

Windows metadata-only corroboration of the no-row/no-rollout pattern.

The same four side-chat IDs checked for #27716 were absent from all persisted stores after the observed App Server restart workflow: 0 matching threads rows, 0 session_index.jsonl entries, 0 sessions rollouts, and 0 archived_sessions rollouts for each ID. This supports the distinction between a live ephemeral thread that can receive turns and a normal persisted thread that thread/fork can resume.

The local Cockpit evidence is limited to request ID, model/account metadata, success or HTTP status, latency, token counts, and estimated cost. It contains no request or response body, and no private logs or databases are attached.

This Windows case supports the proposed app-server behavior: if a source is still loaded, pathless, and ephemeral, thread/fork should be able to promote it from in-memory response history before restart; normal persisted fork behavior should remain unchanged. See #27716 for the discoverability side of the problem.

theophanemayaud · 23 days ago

Same here: when trying to fork threads, I often get a failure to fork which is really annoying as a side thread might have turned into important work and need to be "elevated" into main work.

cvansteenburg · 20 days ago

I can confirm this issue is still live. It happens for me when forking side-chats in the codex app on MacOS. Forking to the same workspace or a new worktree gives me the same missing rollout related error.

shleder · 9 days ago

When side chats or subagent forks fail with no rollout found, it often stems from uncommitted rollout pointers or subagent parent/child lineage breaks in local session state.

You can inspect subagent hierarchies and local session rollouts using Codex Rescue:

npx --yes codex-rescue doctor --latest

Or view agent session graphs:

npx --yes codex-rescue graph --latest

It operates entirely locally and read-only without modifying session files. If you test it, the finding codes or graph summary would help identify the lineage drop.