App UI gets stuck after some work (background work continues)

I've encountered the same problem several times with this version, and now with the latest version, I don't know under what circumstances it will suddenly act like the GUI is stuck communicating with the backend of the App, and all interactions with the GUI are responded to but remain in a loading state, and I can only re-open the App after exiting it completely.

I'm facing this issue regularly to the tune of every 10 minutes or so.

It seems like an issue with a recent release. It's a disruptive bug – restarting the app means you may be halting the agent's run, but you don't know if the agent is running because the UI is stale.

I do not know how to reproduce the issue.

Reproduction:

• Set model to gpt-5.3-codex (high)
• Start a new thread in project A
• Send message: "Spawn 4 subagents, have them each browse my codebase."
• Start a new thread in project B: "Spawn 4 subagents, have them each browse my codebase."
• Start a new thread in either conversation, say "hi". If the ui does not lock up, wait a few seconds and start a new thread and say "hi". The UI will almost always lock up after the second or third new thread.

Are all of you who are experiencing this using the experimental subagents ("collab") feature?

@etraut-openai For me, yes.

@etraut-openai collab is enabled in my config.

@etraut-openai I also have collab enabled.

@etraut-openai I'm having the same issue, even though I haven't enabled collab. Instead, I use codex mcp-server to leverage subagents.

Also seeing this a lot (especially with automations - I woke up to 10 spinning in the UI without doing any visible work, though I can resume the sessions in the TUI and see they actually did complete).

collab = true

It‘s not really making fun and btw I don‘t see anything that looks or feels like giving me 2x usage limit. Feels more like draining usage and extra tokens…

Encountering the same issue, especially when conversation grows longer and longer. Maybe a memory leak somewhere? Restarting seems to help.

@etraut-openai I continue to encounter this issue with collab turned off, turned off since yesterday.

I tried reproduction this issue on Codex VS Codex and Codex CLI – no issue with either.

If you folks still have have the dmg of Codex App (Version 260203.1501), try downgrading to that. (You have to block network connections to persistent.oaistatic.com to prevent the app from automatically updating.)

It's worth it, imo, the performance is night and day.

Investigated by Codex.

I(Codex) compared local logs from Codex Desktop vs Codex CLI on 2026-02-10 under similar multi-thread usage.

Environment:

• Desktop app: 260208.1016 (codex-desktop@260208.1016)
• CLI: codex-cli 0.98.0

Desktop failure signature (single burst window):

• 16:15:04Z to 16:19:16Z
• 393 lines of unknown conversation
• 715 lines of Conversation state ... not found
• 3 lines of turn/completed for unknown conversation
• Completion-like events still arrive, but mapping to local conversation state fails in electron-message-handler.
• The IDs in this burst are different from normal conv=... notification IDs in the same log.

CLI behavior around analogous state inconsistencies:

• Frequent state db missing rollout path ...
• Immediately followed by state db record_discrepancy ... falling_back
• Session/tool processing continues after fallback (no equivalent UI freeze observed in CLI).

Likely cause (hypothesis):

• Desktop has a client-side conversation-state reconciliation/routing race (likely amplified by concurrent threads and/or subagent-like fanout).
• CLI appears to handle similar state mismatches as recoverable via explicit fallback paths, so they are noisy but not fatal.

If useful, I can share a sanitized timeline table (event sequence + counts) from this same run.

Further investigation result (investigated by Codex)

I traced the exact unknown conversation IDs from the Desktop errors, and they are valid subagent thread IDs (not random/stale IDs).

What I found:

• In the parent thread session JSONL, there are 3 spawn_agent calls.
• Those calls return 3 concrete agent_id values via function_call_output.
• Later in the same parent thread, there are matching close_agent calls for those exact IDs.
• Each child session file has session_meta.source.subagent.thread_spawn.parent_thread_id pointing back to the same parent thread.

Why those IDs are being used:

• They are the routing keys for subagent item/* and turn/* events.
• They are also the lifecycle keys (close_agent) and thread lookup keys in local state DB.

Desktop vs CLI behavior for the same IDs:

• Desktop receives item/started, item/completed, and turn/completed for those IDs, but logs:
• unknown conversation
• Conversation state ... not found
• CLI logs the same IDs as:
• state db missing rollout path for thread ...
• immediately followed by record_discrepancy ... falling_back

Further narrowing:

• This does not look like “subagent exists => guaranteed error.”
• The stronger condition from logs is: child events arrive at Desktop, but the child conversation is not registered/hydrated in Desktop state.
• In the same Desktop log, normal conversations have explicit Conversation created: lines, but the failing 3 subagent IDs do not have such lines.
• Timing correlation is tight: first unknown conversation appears ~1–2s after the spawn_agent IDs are returned; last error timestamp per child aligns with each child thread's last event timestamp.

Interpretation:

• The IDs themselves are valid and intentional (subagent threads).
• The failure mode is likely a Desktop conversation-state registration/reconciliation gap (or race) during subagent event routing.
• CLI appears to survive analogous lookup misses via a fallback path, while Desktop repeatedly logs unknown/not-found and can end up with stale/spinning UI.

Current limitation:

• I could not yet pinpoint the exact sync trigger name in Desktop internals because app-server payload logs are summarized (object key counts only), so exact hydration trigger timing is not directly visible in available logs.

Tentatively speaking, Version 260210.1703 (602) seems to fix this.

+1 with @guidedways (https://github.com/openai/codex/issues/10859), it would be great to have release notes for Codex App so we don't have to poke around with each release to see what was fixed.

I still have the issue after upgrading to the latest version

@gemimaernest, do you have the experimental multi-agent feature enabled? Can you provide any other repro steps?

@etraut-openai No multi-agent feature enabled. Since the latest updates, the app lags and freezes a lot (when i switch treads, it takes time to load, the result is slow too). I have an old dmg version of the Codex App 260202.0859 (517) and when i install it, everything is smooth, no freeze.

@gemimaernest, thanks for the details. When you say "latest updates", have you tried version 602, which was released about 12 hours ago?

@etraut-openai Yes I did. I still had the issue

sometimes when I toggle the diff panel in codex app, the window stuck and even crash. The system is macos tahoe.

We've fixed a number of bugs in this area. This bug report hasn't received any upvotes or additional posts in over a month, so I suspect the underlying problem is fixed. If you're seeing a similar symptom with the latest release, please open a fresh bug report with details.