Codex Desktop threads remain spinning after long gpt-5.5/xhigh turns, compaction, and interruption on macOS

Summary

Codex Desktop on macOS intermittently leaves threads stuck in a visible "thinking" / spinner state with no assistant output. This is happening across multiple real work threads, especially after long sessions, high context usage, compaction, and/or interrupted turns.

The most recent case looked like a long turn that started, never surfaced assistant output, and had to be interrupted after several minutes. Nearby logs also show older threads resuming with markedStreaming=true even when the latest turn status is already completed or interrupted, which seems consistent with a Desktop/session lifecycle state sync problem rather than a simple model latency issue.

This looks related to, but not necessarily fully covered by:

• #21360
• #20754
• #14251
• #12852
• #19980

Environment

• Codex Desktop app version: 26.519.41501
• Platform: macOS 26.5, Darwin 25.5.0, arm64
• App process path: /Applications/Codex.app
• Electron version observed from Crashpad annotation: 42.1.0
• Main configured model: gpt-5.5
• Configured reasoning effort: xhigh
• Sandbox mode: danger-full-access
• Local Codex data sizes at the time of diagnosis:
  • ~/.codex: about 4.1G
  • ~/Library/Application Support/Codex: about 215M
  • ~/Library/Logs/com.openai.codex: about 192M

User-visible symptoms

• Threads can remain stuck showing the spinner / "responding" state.
• No assistant text appears for several minutes.
• Clicking Stop / interrupting is often required.
• A fresh thread tends to work more reliably than continuing the affected long thread.
• The symptom appears worse in older/longer threads with a lot of accumulated context/tool history.

Case A: long existing thread resumes with streaming marker still set

One affected long thread resumed with:

maybe_resume_success
conversationId=019e1b2f-eb22-76d0-a8dd-c21ded216ba3
latestTurnStatus=interrupted
markedStreaming=true
turnCount=358

Around the same resume, Desktop also logged:

thread/goal/get errorCode=-32600
goals feature is disabled
Failed to hydrate thread goal after resume

This thread then accepted another turn/start, but the visible Desktop UI remained in a spinner/waiting state from the user's perspective.

I also saw other resume records in the same Desktop log where latestTurnStatus=completed still had markedStreaming=true, for example:

latestTurnStatus=completed markedStreaming=true turnCount=120
latestTurnStatus=completed markedStreaming=true turnCount=65
latestTurnStatus=completed markedStreaming=true turnCount=9

That seems suspicious because completed turns should not remain marked as streaming in the live Desktop UI state.

Case B: recent engineering-review thread stuck until interrupt

Recent affected thread:

conversationId=019e5fda-3cb8-7bd2-82dc-822c6f04083b

The Desktop log showed a normal sequence of successful prior turns in this thread, with turn/start, IAB lifecycle route capture, route resolution, route end, and sometimes show turn-complete.

The problematic turn:

2026-05-25T17:09:42.754Z turn/start
conversationId=019e5fda-3cb8-7bd2-82dc-822c6f04083b

2026-05-25T17:09:42.762Z IAB_LIFECYCLE captured turn route
turnId=019e601d-22e1-7b10-a8bd-cd131d8b54cd

The UI kept showing the spinner with no useful assistant output. After waiting several minutes, the user interrupted it:

2026-05-25T17:17:27.476Z IAB_LIFECYCLE resolved browser use route
turnId=019e601d-22e1-7b10-a8bd-cd131d8b54cd

2026-05-25T17:17:27.477Z IAB_LIFECYCLE ended browser use turn route
turnId=019e601d-22e1-7b10-a8bd-cd131d8b54cd

2026-05-25T17:17:27.585Z turn/interrupt
conversationId=019e5fda-3cb8-7bd2-82dc-822c6f04083b

I did not see a corresponding show turn-complete for that turn between start and interrupt, while nearby successful turns in the same thread did emit turn-complete notifications.

Immediately after, a new turn started:

2026-05-25T17:17:29.065Z turn/start
conversationId=019e5fda-3cb8-7bd2-82dc-822c6f04083b

2026-05-25T17:17:29.071Z IAB_LIFECYCLE captured turn route
turnId=019e6024-4068-77f1-9cc6-c6b5a170f975

That later turn involved a very large context and eventually logged a completed response:

event.kind=response.completed
input_token_count=119840
output_token_count=310
cached_token_count=118144
reasoning_token_count=14
tool_token_count=120150

This suggests the backend/agent can sometimes continue or complete work, while the Desktop UI state still appears unreliable around long turns and interrupts.

Other suspicious Desktop log records

In the same Desktop log, I also saw repeated "unknown conversation" errors near thread creation/start activity:

Received turn/started for unknown conversation
conversationId=019e5fda-c80d-7623-9859-2871e93639f0

Received turn/started for unknown conversation
conversationId=019e601d-aa04-7cf1-af54-40ac1ae586c8

These may be unrelated, but they occurred in the same period as the stuck/spinner behavior.

There was also at least one responses/compact request observed in local logs during nearby long-context Codex activity:

POST api.path="responses/compact"

Resource observations

While diagnosing, Codex Desktop had visible local UI/rendering load:

Codex Helper GPU process: high CPU, observed around 50%
Codex renderer: observed around 20-25%
Codex app-server: observed around 20%

Thermal diagnostics did not report CPU throttling:

No thermal warning level has been recorded
No performance warning level has been recorded

Memory pressure was non-trivial at the time:

16 GB RAM
about 96 MB unused
compressor active
swapins/swapouts present

Expected behavior

• If a turn is still running, Desktop should show active progress and eventually either stream output or surface a timeout/error.
• If a turn is interrupted, the thread should move to a terminal interrupted/failed state and the composer should become usable.
• If a turn has completed, markedStreaming / live UI spinner state should be cleared.
• Long-context compaction should not leave the visible thread in a permanent spinner state.

Actual behavior

• The visible Desktop thread can remain spinning with no assistant message.
• Long turns can require manual interruption.
• Resume records can show markedStreaming=true even for completed or interrupted latest turn statuses.
• Continuing the affected old thread is less reliable than starting a fresh thread.

Privacy note

I am not attaching full local logs or rollout files publicly because they contain private prompts, local paths, and project details. I can provide additional redacted log tails privately if useful.