codex - 💡(How to fix) Fix Codex Desktop accepts prompt but UI stays stuck in Thinking; Stop fails and turn can become invisible after restart

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

Codex Desktop 26.519.41501 (CFBundleVersion 3044)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 15.6.1 build 24G90
arm64
Apple M1 Max
64 GB RAM

Local app/runtime details observed from the installed app and local Sentry scope:

Bundle id: com.openai.codex
Electron: 42.1.0
Chrome runtime: 148.0.7778.97
Sentry release: [email protected]

What issue are you seeing?

Codex Desktop intermittently accepts prompts and continues executing backend work, but the Desktop UI loses reliable active-turn/session state. The visible chat can get stuck in Thinking, stop showing progress traces, show stale or missing turn state, or disagree with other UI surfaces about whether work is active.

I would consider this a major/critical issue, not a cosmetic UI bug, because the Desktop UI is the primary observability and control surface for active Codex execution. If trace visibility, active-turn state, and Stop/cancel state desynchronize, the user loses reliable control over active background work.

Important clarification: I have not observed an app crash, renderer crash, or automatic reload before this happens. The app can remain open. The issue appears to be that the renderer-visible session/turn/trace state becomes detached, stale, frozen, missing, or incompletely rehydrated while backend work may still be running.

The core bug:

• the session/turn appears active or was already visibly active;
• the UI can be stuck on Thinking;
• the prompt bar may show an active turn with the Stop button, or in some /goal cases may incorrectly show Send while the goal bar still says the goal is actively pursuing;
• no new progress traces appear, even while usage may continue decreasing;
• Stop may be unavailable, misleading, or unresponsive;
• the UI does not reliably reflect what the backend is actually doing.

This has happened intermittently for roughly a month. It appears random, but it may be more likely with long-running sessions/threads, trace-heavy turns, subagents/tools, compaction, multi-window use, /goal, or after a relogin/auth flow while the app remains open.

Observed failure modes

1. Prompt accepted, UI stuck in Thinking, Stop fails

Basic pattern:

• I send a prompt.
• The UI stays stuck on Thinking.
• Pressing Stop does not stop the turn.
• I am forced to quit/restart Codex Desktop manually.
• After restart, the thread can look like my prompt was never sent, or it can show later assistant progress without showing the prompt and/or traces that happened while the UI was stuck.
• Because the UI makes it look like the prompt was not accepted, I may resend the prompt.
• Later recovered state proves the original prompt was accepted and the backend/agent had been working the whole time.
• In previous occurrences, trying to recover by resending the prompt or forking the chat has produced errors along the lines of cannot find session / missing session.

2. Live trace/progress stream disappears

When this bug happens, it is not only the final assistant message or prompt bubble that can be affected. The live trace/progress stream itself can disappear.

Observed variants:

• stuck Thinking with no traces shown, even though backend work appears to continue;
• restart can remove traces that were previously visible;
• for long tasks, the trace stream can randomly reattach later without restart;
• sending a follow-up prompt has sometimes appeared to unstick/reconnect the trace stream.

3. /goal state split and multi-window rehydration failure

This also appears associated with the /goal feature, and the order of events matters.

Corrected repro order from one occurrence:

1. I had already started the goal via a prompt in the original window.
2. The goal was working normally.
3. The original session UI was showing the prompt/goal progress traces normally.
4. The prompt box was correctly showing the Stop button, indicating an active turn was running.
5. Only after that, I tried opening the same session in a new Codex window.
6. In the new window, the session failed to load or did not finish loading the active session state.
7. At that point, the already-visible goal/prompt progress traces disappeared in both the new window and the original window.
8. Both windows then looked as if the active turn/progress had been lost in the chat/trace area, and the prompt box showed Send instead of Stop. However, the goal bar above the prompt box still showed the goal as actively pursuing, not paused or stopped.
9. After waiting some time, all of the traces that had previously been visible spontaneously appeared again, and the prompt box changed back to Stop.

This is different from the UI simply failing to show traces from the beginning. The traces and active Stop state were visible and working first. Opening the same session in a second window appears to have caused the Desktop UI to lose or detach the already-visible active turn/session state across all windows.

The especially strange part is that different parts of the same UI disagreed about whether work was active: the goal bar still showed an active pursuing-goal state, while the chat/trace area lost the active progress and the prompt box reverted to Send. That suggests a session/turn state split between the goal-level active state and the visible turn/trace/input state.

4. Multi-window active-session monitoring can freeze/detach visible progress across sessions

This is especially concerning when trying to monitor multiple active Codex sessions at once. My goal was to open each active session in its own Desktop window so I could watch each one progress, instead of manually switching between sessions inside a single window.

Observed behavior:

• one existing window/session had been showing the active turn's persisted traces/progress correctly;
• after trying to open active sessions in new windows, one of the windows hit the session loading/rehydration issue;
• after that, visible progress across the sessions/windows appeared to become frozen or detached;
• all of the sessions I had opened in new windows stopped showing new traces;
• the backend presumably continued working in the background, but the Desktop UI stopped showing new trace/progress updates;
• this makes the UI unreliable as a monitor for active work, because it can show no progress even while work may still be running.

This may be connected to very long sessions/threads. These sessions are long-running and trace-heavy, and it is starting to look possible that the app is failing to consistently load or rehydrate long session state unless I completely quit and restart the app.

5. Confirmed active backend usage while UI is frozen

This now appears confirmed as active backend execution with a frozen/detached Desktop UI.

Across multiple active sessions:

• the UI shows the sessions as Thinking;
• the prompt box shows the Stop button, indicating an active turn;
• no new progress traces or activity are visible in the app;
• the visible state appears frozen;
• however, my usage dashboard is actively decreasing while this is happening.

That strongly indicates Codex is still executing and using model resources in the background, but the Desktop app is not showing any of the activity, traces, or progress. The issue is not simply that the model stopped or that the turn is idle. The backend appears active while the UI is detached from the running turn state.

Concrete evidence from one occurrence

After restart/recovery, the visible history showed that the original stuck turn had actually continued doing work. It showed status/progress like:

Steered conversation
The previous commit-boundary reviewer handle is not available in this resumed tool session, so there’s no valid approval artifact to consume. A new prompt delta just arrived too; I’m checking it against the already registered EK-DOCS-SYNC delta before I touch any gate state.

Explored 1 file, ran 2 commands
The repeated EK-DOCS-SYNC directive is already represented in the repo-local prompt-delta artifact and successor proof: full docs-state backfill, coverage matrix, canonical docs, and explicit forbidden actions are all present. I’m going to have the commit-boundary reviewer independently verify that duplicate/newest prompt is covered before approving the commit boundary.

Spawned 1 agent

Ran 3 commands
The reviewer is running while I keep my side read-only. One local inspection hit a harmless parsing assumption in VALIDATION.json; I’m not treating that as a repo failure, just as a cue to use the file’s actual schema when refreshing validation later.

The independent commit-boundary gate is approved with no findings, including the repeated EK-DOCS-SYNC directive check. I’m closing that reviewer and recording the gate outcome into repo-local artifacts/state before moving to commit approval.

From the user perspective before the manual restart, the app was simply stuck in Thinking, Stop did not work, and I could not see that work. I resent the prompt because the UI made it appear as if the prompt had not been sent.

Impact

• Active agent work may continue while the UI appears frozen, stale, or detached. Usage can continue decreasing while no traces/progress are visible.
• The user cannot reliably observe what Codex is doing.
• The user cannot reliably determine whether a turn is active, stopped, detached, or invisible.
• Stop/cancel may be unavailable, misleading, or unresponsive.
• The visible chat history can be misleading after restart.
• Duplicate prompts can be created because the original prompt is hidden or appears unsent.
• Resend/fork recovery paths can hit missing-session style errors.
• Long-running workflows with subagents/tooling can be duplicated, conflicted, or left running invisibly.
• Multi-window monitoring of active sessions becomes unreliable because opening/loading one session can appear to freeze or detach visible progress across windows.

For an agentic desktop app that can run tools, spawn agents, and work on repositories, reliable active-turn state, trace visibility, and cancellation are core safety/control surfaces. If those desynchronize, the app becomes unsafe/unreliable for serious long-running work.

What steps can reproduce the bug?

I do not have a deterministic repro yet. Observed patterns:

Basic stuck Thinking / invisible turn path

1. Use Codex Desktop on macOS during a long-running local workspace thread.
2. Keep the app open. In some cases this may happen after a relogin/auth flow.
3. Send a prompt.
4. The UI remains stuck on Thinking after the prompt.
5. Try pressing Stop. It does not stop the turn.
6. Manually quit/restart Codex Desktop.
7. Reopen the thread.
8. The prompt/trace may be missing or partially recovered, even though later state shows the agent had been executing the prompt.
9. If the prompt is resent because it looks unsent, it may later appear as a steered/duplicate continuation, or recovery actions like forking can hit missing-session errors.

/goal / second-window rehydration path

1. Start a /goal turn via prompt.
2. Let it run normally in the original window.
3. Confirm traces/progress are visible and the prompt box shows Stop.
4. Open the same session in a new Codex Desktop window.
5. The new window fails to load or does not finish loading the active session state.
6. Already-visible traces disappear in both windows.
7. The goal bar still shows actively pursuing, but chat/trace state disappears and the prompt box may show Send instead of Stop.
8. After waiting, traces may spontaneously reappear and the prompt box may return to Stop.

Multi-window active-session monitoring path

1. Have multiple long-running active sessions.
2. Open each session in its own Desktop window to monitor progress.
3. One or more windows fail to load/rehydrate active session state completely.
4. Visible progress traces across sessions/windows stop updating or appear frozen/detached.
5. Backend work may still be running, but the UI no longer reliably shows progression.

Local state observations

Sanitized local state observations from the same app session:

• Local Sentry scope had active app-state snapshots during the session.
• Breadcrumb counts included:
  • method=turn/start: 2
  • method=turn/steer: 1
  • Item not found in turn state: 2
  • app_state_snapshot: 26
• App-state snapshots repeatedly included active/streaming mismatch indicators:
  • thread_count_active: 4
  • thread_count_streaming_owner: 3
  • thread_count_streaming_without_role: 1
  • thread_count_streaming_without_active_runtime: 2-3
  • thread_count_with_inflight_turn: 1-2
  • inflight_turn_count: 1-2
  • browser_use_active_turn_route_count: 1-2

I am not claiming this is the same as reports involving a confirmed crash/reload, placeholder rebinding, or thousands of Item not found in turn state errors. The observed user-facing bug here is: prompt accepted and executed, UI stuck in Thinking or active-turn state becomes detached/frozen, Stop/Send state becomes misleading, and visible prompt/trace/session state is missing or misleading until restart or later rehydration.

What is the expected behavior?

If Codex Desktop accepts a prompt or continues a goal, it should durably and visibly associate that backend turn with the originating thread/session across windows.

Expected behavior:

• The user prompt should remain visible after submission.
• Assistant progress, tool calls, subagent activity, and traces should stream reliably while work is active.
• Active turn state should be consistent between the goal bar, chat/trace area, and prompt box.
• Opening the same session in another window should not detach or clear traces in the original window.
• Opening multiple active sessions in separate windows should not freeze visible progress streams across sessions.
• Stop should reliably cancel the backend turn or show why it cannot.
• If the renderer/thread UI loses ownership of an active backend turn, the app should show a recovery/reattach state instead of generic stuck Thinking or misleading Send/Stop state.
• Resending or forking should not produce missing-session errors or duplicate/steered turns because of hidden accepted prompts.
• Long sessions should either load/rehydrate reliably or show an explicit loading/recovery state that does not erase visible active traces.

Additional information

This seems like a session/turn state ownership or trace-stream subscription problem between the Desktop UI and the backend/app-server. The backend appears to accept and execute prompts, but the UI can fail to show the submitted prompt, active stream, tool traces, goal/turn alignment, and cancellation state.

The main issue is not one exact repro path. It shows up through /goal, multi-window session opening, long-running turns, restarts, and sometimes follow-up prompts. The common failure is that the Desktop UI does not reliably and consistently show the real active state, progress, and trace stream for running sessions, especially long sessions.