Codex Mac Desktop App: existing threads don't load after app restart

[joshp123]

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.325.31654 (1272)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.1.0 arm64 arm

What issue are you seeing?

I had a bunch of open threads (not archived) open in the Codex app, after a restart they are all gone in the UI, but still present on disk.
Except the pinned threads, somehow they remain.

From Codex itself:

The first bad loads show up on April 4, 2026 at 12:23:38Z in codex-desktop log (line 1858). Your user config in config.toml was last modified at April 4, 2026 23:15:11, and the current app bundle app.asar is from March 28, 2026. So the timing does not fit “we changed config, then sessions broke.”

What the source shows: this is a Codex Desktop subagent-thread bug. I extracted the renderer chunk to app-server-manager-hooks.js. In there, the app hydrates spawned/collab receiver threads with a thread/read using includeTurns:false, and separately the turn/started handler just errors out if the conversation is not already in memory. That creates a race. Your logs match it exactly: for this spawned session (line 1), the session is created at 18:57:21.934Z, then the log (line 21320) shows thread/read, and 95ms later the same log (line 21321) shows Received turn/started for unknown conversation, followed by No turns for conversation. That means the child thread starts emitting turn events before the renderer has inserted conversation state.

There’s a second real bug in the bundle too: the desktop code parses source.subAgent, but your stored thread/session metadata is source.subagent lowercase in state_5.sqlite and the session files. That likely breaks subagent-specific UI wiring, but it looks older and latent. The race above is the thing that matches today’s failure pattern.

More clanker slop:

After restarting Codex App, almost all previous sessions stopped loading. The only old sessions that still seem to load are pinned ones.

Important detail: this does not look like session data was deleted. The session files still exist locally on disk, but the app fails to load them after restart.

From the app logs, the failure pattern looks like this:

• the app successfully reads the thread
• then it immediately treats incoming turn/item events as belonging to an unknown conversation
• then it reports that there are no turns / no conversation state for that same conversation

Example from the logs for conversationId=019d59db-5e0a-74c3-88a0-686072ee40fe:

• 2026-04-04T18:57:22.374Z: response_routed ... method=thread/read conversationId=019d59db-5e0a-74c3-88a0-686072ee40fe
• 2026-04-04T18:57:22.469Z: Received turn/started for unknown conversation conversationId=019d59db-5e0a-74c3-88a0-686072ee40fe
• 2026-04-04T18:57:23.416Z: No turns for conversation conversationId=019d59db-5e0a-74c3-88a0-686072ee40fe

Another example for conversationId=019d5918-fa4e-74d1-9ed2-cb69be48e455:

• 2026-04-04T15:25:02.606Z: Received turn/started for unknown conversation conversationId=019d5918-fa4e-74d1-9ed2-cb69be48e455
• 2026-04-04T15:25:03.452Z: Received item/started for unknown conversation conversationId=019d5918-fa4e-74d1-9ed2-cb69be48e455
• 2026-04-04T15:25:03.452Z: Received item/completed for unknown conversation conversationId=019d5918-fa4e-74d1-9ed2-cb69be48e455
• 2026-04-04T15:25:03.840Z: Conversation state not found conversationId=019d5918-fa4e-74d1-9ed2-cb69be48e455

So the user-visible symptom is:

• restart app
• pinned sessions still load
• non-pinned previous sessions mostly or entirely fail to load
• local session data still exists
• logs suggest the app is reading thread metadata but failing to reconstruct / retain conversation state

What steps can reproduce the bug?

Uploaded thread: 019d59e6-805e-7f53-af2e-d474db002e07

What is the expected behavior?

All the threads on disk load in the app 😁

Additional information

No response

[github-actions]

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

• Lost part of thread history and all subagent thread history after Codex App restart. #16599
• Threads randomly disappear from history without deletion (possible sync/cache issue) #15406
• Loss of large amount of recent conversation turns / history / context after app restart #15349
• Worktree conversation remains listed in Settings but disappears from sidebar thread list #16811
• threads missing at every single start of codex for windows #15052

Powered by Codex Action

[joshp123]

@etraut-openai I don't think this is a duplicate of #15406.

• That ticket describes threads disappearing randomly - in this case, it's not random threads - its all of them (except pinned ones)
• Threads stay in Codex CLI history and can be resumed with /resume - in this case, the threads are not visible from the Codex CLI at all, and cannot be resumed.

Can you consider re-opening this?

[etraut-openai]

@joshp123, I think this is the same underlying problem. We like to consolidate problems that are likely to be the same issue because it boosts their visibility to the team. If there are a bunch of separate bug reports with little or no engagement from other users, they tend to fly beneath the radar.

That said, if you think this is truly a different issue, I'll reopen this one.

[joshp123]

Hey @etraut-openai , thanks for the response and re-opening the issue - I appreciate it. Totally understand consolidating duplicates, no criticism there :)

One more additional datapoint (that also diverges from the linked ticket) - it seems like my preferences for the Codex app (and possibly CLI) also got reset around the same time. I'm having Codex look into the issue; will keep the issue updated with additional information and enrich the issue with this.

[yahuo]

Additional evidence from a renderer/sidebar-only variant on macOS. This may be the same umbrella symptom as #16095, but on my machine the failing layer is clearly the Desktop renderer, not local storage or the app-server.

Environment

• Codex Desktop: 26.409.20454 (build 1462)
• macOS: Darwin 25.x on arm64
• active workspace: /Users/jinxin/Applications/OpenSource/claude-code

What is healthy

• ~/.codex/state_5.sqlite contains 12 unarchived threads for that exact cwd.
• The rollout/session files for those threads still exist on disk.
• Querying the same local app-server that the Desktop app uses returns those missing threads correctly via thread/list for that exact cwd.
• On this machine, all of the following return the expected rows:
  • thread/list({ cwd=..., archived=false })
  • thread/list({ cwd=..., archived=false, sourceKinds=[] })
  • thread/list({ cwd=..., archived=false, sourceKinds=null })
  • thread/list({ cwd=..., archived=false, sourceKinds=["vscode"] })

Observed UI symptom

• In project view, the left sidebar showed only the current thread under that project.
• Restarting the Desktop app did not restore the missing local threads.
• Pinned / otherwise already-hydrated threads could survive, which made this look like a client-side hydration/rendering problem.

What I validated locally

• I extracted the current Desktop bundle and patched the renderer chunks (app-server-manager-hooks-*.js and app-server-manager-signals-*.js).
• A local patch that does the following restored the missing sidebar threads on my machine:

1. In the recent-conversations manager, refetchThreadList() must page through all thread/list cursors, not only the current 50 * pageCount window.
2. In the sidebar query hook, the React Query cache must be populated from a full merged listAllThreads({ archived:false }) result, not seeded from the current in-memory recent-conversation subset and then left vulnerable to being overwritten by that partial state.

After applying that renderer-side patch locally:

• the missing project threads reappeared in the left sidebar
• the app still launched cleanly after repacking, updating ElectronAsarIntegrity, and re-signing

Important upstreaming blocker

• I checked the public openai/codex repo to try to send a PR.
• The public repo contains the CLI / app-server / SDK pieces, but not the Electron Desktop renderer/webview source for this sidebar path.
• codex app in the public repo only downloads/opens Codex Desktop; it does not contain the sidebar implementation I had to patch.

So from the outside this looks like an internal Desktop-source fix, not something that can currently be fixed with a public PR against openai/codex.

If useful, I can post the exact local patch shape I validated, but the short version is: the backend thread/list layer is healthy here; the failing layer is renderer-side recent-conversation pagination/cache hydration in the Desktop app.

[vernon99]

Just wanted to chime in here, happened to twice in the last 30 minutes, removing first a bunch of chats after restart and then removing the rest. Almost all of mu chats are gone, ugh.