Codex Desktop accepts prompt but UI stays stuck in Thinking; Stop fails and turn can become invisible after restart

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

• #24263
• #24217
• #23292

Powered by Codex Action

Additional detail about the visible trace/progress stream:

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:

1. Stuck Thinking with no traces shown

Sometimes after I send a prompt, the UI gets stuck on Thinking and none of the traces/steps/progress are shown, even though the backend appears to be working.

1. Restart can remove traces that were previously visible

After manually quitting/restarting the app, the reopened thread can be missing parts of the thread that were previously present. In particular, if I send a prompt during an active turn and the app bugs out, then after restart the entire previous turn's traces can be gone from the visible UI.

1. Trace stream can randomly reattach later without restart

For long tasks, Codex normally shows progress/traces continuously during the turn. When the bug happens, it may show only Thinking and nothing afterward for a long time. If I wait an extended time, the UI can randomly resume showing traces again before the turn finishes.

1. Follow-up prompt can sometimes unstick the trace stream

In at least one occurrence, I sent another follow-up prompt while it was stuck, and that appeared to unstick the UI: the thinking/progress traces started showing again.

This makes the bug feel like a live turn trace/session subscription or ownership desync. The backend work can continue, but the renderer-visible thread can stop receiving or rendering the active turn's trace events. Later, the UI may reattach spontaneously or after another prompt, but restart can also cause previously visible traces to disappear from the reconstructed thread view.

This is essentially the same thing I'm seeing in my issue https://github.com/openai/codex/issues/24263

---
title: "Codex Desktop accepts prompt but UI stays stuck in Thinking; Stop fails and turn can become invisible after restart"
issue: https://github.com/openai/codex/issues/24287
repo: openai/codex
type: bug-fix
area: app, session, app-server
competition: low (3 comments, but no solution proposed)
quote: $1,500-$2,500
---

Complete Solution

Root Cause Analysis

This is a session/turn state ownership desync between the Codex Desktop UI (Electron renderer) and the backend/app-server. The core issue:

1. Prompt accepted but UI loses ownership: The backend accepts and executes the prompt, but the UI's turn subscription fails to receive or render the prompt bubble, assistant progress, and tool traces
2. Stop fails: The Stop button can't cancel because the UI doesn't have a valid reference to the active turn
3. State invisible after restart: The thread's prompt/trace state is not durably associated with the originating thread, so restart shows misleading or missing history

Key evidence from Sentry breadcrumbs:

• thread_count_active: 4 but thread_count_streaming_owner: 3 — one active thread has no streaming owner
• thread_count_streaming_without_role: 1 — a streaming thread has no role assigned
• thread_count_streaming_without_active_runtime: 2-3 — streaming threads with no active runtime
• Item not found in turn state: 2 — turn state lookup failures

Fix — Three-Layer Approach

Layer 1 — Turn ownership reconciliation (primary fix):

// In app-server's turn management (Rust)
// When a prompt is accepted, ensure the turn is durably linked to its thread
// BEFORE any streaming begins

fn handle_prompt(thread_id: &str, prompt: Prompt) -> Result<TurnId> {
    // 1. Create turn record in the thread's durable store FIRST
    let turn = Turn::new(thread_id, prompt);
    self.store.save_turn(&turn)?;  // Durable write before streaming
    
    // 2. THEN start the backend execution
    let turn_id = turn.id.clone();
    self.backend.execute(turn_id.clone(), prompt);
    
    // 3. Subscribe the UI to the turn stream
    self.ui.subscribe(thread_id, turn_id.clone());
    
    Ok(turn_id)
}

Layer 2 — Stop/cancel reliability:

// In the Desktop UI's Stop handler
async handleStop() {
    // Get the current turn_id from the durable store, not just in-memory state
    const turnId = await this.store.getActiveTurnId(this.threadId);
    if (!turnId) {
        // Show recovery UI instead of silently failing
        this.showRecoveryState("No active turn found. Checking backend state...");
        const backendTurn = await this.appServer.findActiveTurn(this.threadId);
        if (backendTurn) {
            // Re-attach UI to the backend turn
            await this.reattachToTurn(backendTurn);
        }
        return;
    }
    await this.appServer.cancelTurn(turnId);
}

Layer 3 — Recovery/reattach state:

// When the UI detects it has lost ownership of an active turn
async detectAndRecover() {
    const localActive = await this.store.getActiveTurns(this.threadId);
    const backendActive = await this.appServer.getActiveTurns(this.threadId);
    
    // Find turns that exist in backend but not in UI
    const orphanedTurns = backendActive.filter(
        bt => !localActive.some(lt => lt.id === bt.id)
    );
    
    for (const orphaned of orphanedTurns) {
        // Show a recovery banner
        this.showRecoveryBanner({
            type: 'orphaned_turn',
            turnId: orphaned.id,
            message: 'An active turn was found that is not visible in the UI. Click to re-attach.',
            action: () => this.reattachToTurn(orphaned)
        });
    }
}

Testing Strategy

• Unit test: verify turn is durably stored before streaming begins
• Integration test: simulate UI crash during active turn, verify recovery on restart
• Edge case: verify Stop works even when UI has lost turn ownership
• Regression test: verify normal turn flow (prompt → stream → response) is unaffected

Files to Change

1. codex-rs/app-server-daemon/src/turn_manager.rs — add durable turn storage before streaming
2. app/src/turn-state-manager.ts — add recovery/reattach logic
3. app/src/stop-handler.ts — use durable turn reference instead of in-memory

Impact

• Prompts are durably associated with their originating thread
• Stop button reliably cancels the backend turn or shows recovery state
• Orphaned turns are detected and recoverable after restart
• No duplicate prompts from invisible accepted prompts

Additional detail: this also appears associated with the /goal feature, and the order of events matters.

Corrected repro order:

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.

That makes the session state shown in the UI feel temporary or incompletely rehydrated: the persisted/streaming state seems to disappear from the renderer until whatever session/turn binding or trace stream loading finishes again. When it reattaches, the missing traces reappear as if they had been there the whole time.

This still does not look like an app crash. The app remains open. The visible session state becomes inconsistent across windows, then later rehydrates.

Additional impact / multi-window observation:

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.

What I observed:

• 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;
• I could no longer reliably see further progress traces in the UI;
• 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.

The concerning failure mode is: opening the same or other active sessions in additional windows can appear to detach or freeze the visible active-turn state across windows, leaving the user unable to tell what is currently running or whether Stop would work.

Core failure mode clarification:

As of now, all of the sessions I opened in new windows are no longer showing any new traces. This is the main problem behind the different variants I have described.

The core bug is:

• the session/turn appears active;
• the UI can be stuck on Thinking;
• the prompt bar may show an active turn with the Stop button;
• but no new progress traces appear;
• the UI does not reliably respond or reflect what the backend is actually doing.

So the issue is broader than one exact repro path. It shows up through /goal, multi-window session opening, long-running turns, restarts, and sometimes follow-up prompts, but 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.

In other words: the app can have an active backend turn, but the renderer-visible session state/trace stream becomes detached, frozen, missing, or stale. That makes the app UI unreliable for monitoring active Codex work and for knowing whether Stop will actually work.

Severity note:

I would consider this a major/critical issue, not a cosmetic UI bug.

Reason: the Desktop UI is the user's primary control and observability surface for active Codex execution. When it stops showing real progress traces, shows inconsistent active state, or leaves the user unsure whether Stop will work, the user loses reliable control over active background work.

Impact:

• active agent work may continue while the UI appears frozen or stale;
• the user cannot reliably observe what Codex is doing;
• the user cannot reliably determine whether a turn is active, stopped, or detached;
• the Stop control may be unavailable, misleading, or unresponsive;
• users may resend prompts or open/fork sessions because the UI makes the active state unclear;
• long-running repo workflows can be duplicated, conflicted, or left running invisibly.

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.

Additional confirmation: 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.

This is the core reliability problem: active work can continue invisibly while the app UI is stuck and provides no usable observability.

I’m seeing the same failure mode on Codex Desktop as well.

In my case, the important part is that the UI appears detached from an active backend turn rather than the turn simply being idle. The thread can remain stuck on Thinking, progress traces stop updating, and Stop either does not work or does not appear to reflect the actual backend state. I have also seen cases where the prompt/turn appears missing after restart even though later state suggests the backend accepted and continued executing it.

My observed pattern:

• Codex accepts a prompt in an existing long-running thread.
• The UI stays on Thinking with no new trace/progress updates.
• The prompt box may still show Stop, but pressing it does not reliably cancel the work.
• Restarting the app may show missing or partial turn history.
• In some cases, usage continues decreasing while the UI shows no visible activity, which suggests backend execution is still active.
• Sending a follow-up prompt or waiting can sometimes cause the trace stream to reattach.

This is especially risky because the UI makes it unclear whether a turn is actually running, stopped, detached, or invisible. From a user-control perspective, the problematic behavior is not just stale rendering; it is loss of reliable observability and cancellation for active agent work.

I can provide app version/platform details and local diagnostics if helpful. Are there specific logs, Sentry scope values, or local state files that would be most useful to capture the next time this happens?

same here

same issue

Follow-up for this issue
I can still reproduce this with:

Codex App version: 26.608.12217
Codex CLI version: 0.139.0
This still matches the same failure pattern:

UI stays in Thinking during an active turn
progress/trace output is not updating reliably
Stop may not appear to stop execution
behavior looks stale or detached from actual backend activity

Extra context on the same stuck thread: the session was already in Plan mode before restart by Codex Desktop update. After restarting to 26.608.12217, UI now shows Plan mode as off, but the thread remains stuck in the Plan execution path and Plan mode cannot be turned off. Workaround that unblocks me: switching reasoning level and continuing there; that allowed the thread to proceed. This seems like a session/state desync, not an actual mode toggle mismatch.

Tracking this from a downstream app-server client / Codex Mobile integration because it matches the same user-visible failure mode: a submitted message can leave the client showing an active/Thinking state while the durable thread state does not reliably show the new turn.

Sanitized local signal from a recent occurrence:

• The client submit endpoint received the message and returned a new turnId from turn/start.
• A follow-up durable read still showed the previous latest completed turn, with no matching newly submitted turn visible.
• The local session JSONL/rollout did not contain the returned turnId or the client submission id after the submit response.
• A local fallback cache then projected the returned turnId as active, which made the Mobile UI look like the session was still thinking even though persistent state had not advanced.

That makes this feel like the same class of session/turn ownership and durable-state desync described here: the user-facing client cannot safely distinguish "accepted and running" from "accepted-looking but not materialized". We have added a downstream guard that verifies the submitted turn is visible via bounded thread state before showing it as active; subscribing here for the upstream fix.

I reproduced this on Windows across the VS Code extension and Codex Desktop using the same local thread.
A /goal was actively running in VS Code. After opening another chat/window and returning, both VS Code and Desktop showed stale conversation state ending several messages earlier. The goal bar still showed the goal as pursuing, but the visible turn appeared stopped.
The local rollout JSONL retained the full history and continued growing, confirming that backend reasoning and tool activity were still running. At the same time, the exposed thread state reported notLoaded and the latest turn as interrupted.
This suggests the rehydration/state-synchronization problem also affects cross-surface VS Code ↔ Desktop usage, not only multiple Desktop windows.