›_ Codex Issues
Codex Issues / #24850

Codex Desktop can remain in Thinking after successful tool calls with no streamed follow-up or a hung /responses request

Open 💬 6 comments Opened May 28, 2026 by susiwen8

Summary

Codex Desktop can remain in the UI Thinking state after tool calls have already completed successfully. After inspecting local session JSONL and core SQLite logs across several affected turns, the visible Thinking state appears to cover multiple distinct backend states:

  1. A stale turn state after a successful tool result, with no further session events emitted until the user interrupts.
  2. A follow-up /responses request that is started after successful tool results but then produces no streamed output for several minutes, until the user interrupts.
  3. Context compaction after tool output, which can look similar in the UI but does eventually resume.
  4. A long-running model request after tool output that eventually returns, also shown only as Thinking.

This makes it hard to tell whether the model is actually reasoning, the backend request is hung, compaction is running, or the turn runner is stale.

Environment

Sanitized environment from affected runs:

  • Product: Codex Desktop
  • Client version observed in logs: 26.519.81530
  • Core/app version observed in telemetry: 0.133.0
  • OS: macOS, arm64
  • Model: gpt-5.5
  • Reasoning effort: xhigh
  • Approval policy: never
  • Sandbox: full local access
  • Auth mode: ChatGPT

Account identifiers, email addresses, exact local paths, thread IDs, and prompt contents have been intentionally omitted.

Observed Patterns

Case A: tool success followed by no session activity until interrupt

In one affected turn, the last tool call was an apply_patch that completed successfully. After the tool result was written, there were no further session JSONL events until the user interrupted several minutes later.

Sanitized event sequence:

T+0s     custom_tool_call_output: apply_patch success
T+0s     token_count
T+216s   user interrupt
T+216s   turn_aborted

During that interval there were no new session entries of these types:

reasoning
message
function_call
function_call_output
token_count
task_complete

This suggests the UI was still showing Thinking, but there was no visible evidence that the model was actively reasoning or that any new tool work was pending.

Case B: tool success followed by a follow-up /responses request that hangs

In another affected turn, multiple shell tools completed successfully. The runner then decided a model follow-up was required and started a new /responses request. No streamed output was produced for over eight minutes, until the user interrupted.

Sanitized session sequence:

T+0s       function_call_output: success
T+0s       function_call_output: success
T+0s       function_call_output: success
T+0s       token_count
T+492.7s   user interrupt
T+492.7s   turn_aborted

Relevant sanitized core log signal:

post sampling token usage
  total_usage_tokens=117208
  estimated_token_count=Some(96568)
  auto_compact_scope_limit=244800
  token_limit_reached=false
  model_needs_follow_up=true
  has_pending_input=false
  needs_follow_up=true

stream_request: POST /backend-api/codex/responses

There was no Request completed log and no streamed reasoning, message, function_call, or token_count event before the interrupt.

This suggests this instance was not local tool execution and not visible local reasoning; it was a pending follow-up model request that did not produce output or a failure event for several minutes.

Case C: tool success followed by context compaction

A separate affected-looking interval was actually context compaction. In that case, tool output completed, then a context_compacted event appeared around 30 seconds later, and reasoning resumed shortly after.

Sanitized sequence:

T+0s    function_call_output: success
T+0s    token_count
T+~30s  context_compacted
T+~35s  reasoning resumes

This is less concerning functionally, but the UI still only showed Thinking, making it indistinguishable from the stuck cases above.

Case D: long follow-up request that eventually returns

Another case showed a post-tool follow-up /responses request taking around 149 seconds before returning. It eventually emitted reasoning, so it was not permanently stuck, but it looked identical to the hung case in the UI while waiting.

Sanitized signal:

POST /backend-api/codex/responses
Request completed: status=200, duration_ms=149510
reasoning emitted afterward

Expected Behavior

After tool calls complete successfully, Codex Desktop should avoid silently staying in Thinking indefinitely.

Ideally:

  • If a follow-up model request is pending, the UI should distinguish "waiting for model response" from "reasoning".
  • If a follow-up /responses stream produces no events for a long time, Codex should emit a timeout, retry, or visible recoverable error.
  • If the runner has needs_follow_up=true but no progress occurs, there should be watchdog logging and a task-level failure or recovery path.
  • If context compaction is running, the UI should identify that state separately.
  • If no model request is pending and no events are emitted after tool success, the turn should not remain open without task_complete, turn_aborted, or an error event.

Why this matters

From the user's perspective, all of these cases look like the same Thinking state after tools have already succeeded. The only practical workaround is to interrupt the turn and continue, but interruption can lose momentum and may leave turns in confusing states.

Agent-level instructions such as "after tool success, promptly respond" do not fix the hung cases because the model does not regain control while the follow-up request is pending or the runner is stale.

Potentially Related Issues

This may overlap with or provide more granular diagnostics for:

  • #24336
  • #21360
  • #24571
  • #24618

View original on GitHub ↗

6 Comments

fiftidollar · 2 months ago

+1 to THIS!!!!!!! YES! PLEASE

grnbtqdbyx-create · 2 months ago

I added a small detector for this exact report shape in trace-to-skill@0.1.60:

npx trace-to-skill@0.1.60 demo thinking-hang
npx trace-to-skill@0.1.60 codex-report ./runs --output openai-codex-thinking-hang.md

It is not a fix, just an evidence packer for reports like this. It looks for accepted turns or completed local tools followed by no streamed assistant follow-up, long gaps before the first response_item, responses_http / websocket close lines where time.busy is tiny and time.idle is hundreds of seconds, Stop/Ctrl+C failures, MCP state, and subagent parent/child lifecycle evidence.

The goal is to make future reports include the exact timing fields maintainers need without requiring people to paste entire private transcripts.

Ychris12138 · 1 month ago

Additional reproduction evidence: Windows Desktop, gpt-5.6-sol, post-tool continuation intermittently never resumes

I am seeing what appears to be the same failure mode on a newer Windows Codex Desktop build and model. The important additional observation is that this can occur after ordinary local PowerShell/config inspection, without web search, Guardian review, subagents, MCP startup, compilation, or git diff.

Environment

  • Product: Codex Desktop for Windows
  • Windows app package: OpenAI.Codex 26.707.9564.0
  • Embedded runtime: codex-cli 0.144.2
  • Model: gpt-5.6-sol
  • Reasoning effort in affected runs: high
  • Zotero MCP: disabled before the latest reproduction
  • WinHTTP proxy: none
  • HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY: not set
  • ChatGPT, codex, and codex-code-mode-host processes remained alive during inspection
  • A separately installed npm CLI was codex-cli 0.125.0; this is not the runtime used by Desktop

User-visible behavior

The UI remains on the last planning-status text, for example:

Planning code compilation and diff inspection
Planning local Codex version and config inspection

The operation described by that text is not actually still running. The last tool has already returned successfully, but there is no further reasoning item, tool call, final response, visible error, or terminal task state. The task continues to show as running until manually stopped, after which it becomes interrupted.

Observed samples

At least three affected turns have been observed:

  1. About 12m 39s. The last action opened the official Codex changelog. The page result returned, but no final response followed.
  2. About 10 minutes. Several official-document searches and page opens completed, after which no additional model output appeared.
  3. About 22m 29s. The task stopped after local version, process, config, and proxy inspection commands had already returned complete results. No web search, review, subagent, compilation, or pending approval was involved in this sample.

All three turns required manual interruption. There was no evidence of a still-running shell command or app-server crash in the latest sample.

Likely failure boundary

The expected sequence is:

model requests tool
→ tool result returns
→ continuation request starts
→ model output stream resumes
→ final response is persisted

The affected turns fail after the tool result returns. It is not yet clear whether each sample is:

  1. a local scheduling failure where no continuation request is started;
  2. a continuation request whose WebSocket/SSE/HTTP stream never produces output or fails to recover; or
  3. a completed response that is not persisted/rendered and does not close the task.

Historical local logs from the same installation include stream disconnected, repeated retries followed by HTTP fallback, and WebSocket 10054 / 10061 errors. This confirms that response-stream instability has occurred, although it is not yet proven that every stalled turn has the same cause.

Negative/minimal tests

Four clean, short, new-thread tests were run successfully:

  • no-tool response;
  • one PowerShell command followed by a final response;
  • one file read followed by a final response;
  • one web-page open followed by a final response.

Therefore the basic post-tool continuation path is currently functional and the bug appears intermittent or load/state dependent rather than deterministic per tool type.

Potential amplifiers in the failed runs include:

  • reasoning_effort = high;
  • a long first user message / large context;
  • multiple sequential tool round trips;
  • retaining an abnormal turn for 10–22 minutes;
  • prior response-stream disconnects.

Factors not required for the latest reproduction

The latest case occurred without:

  • Guardian or automatic code review;
  • subagents;
  • enabled Zotero MCP;
  • hidden approval prompts;
  • git diff pager;
  • compilation or test execution;
  • an app-server process crash.

Expected behavior / diagnostic request

After a successful tool result, Desktop should not remain indefinitely in a generic planning/thinking state. It would help if the UI and durable logs distinguished:

  • tool completed, continuation not yet dispatched;
  • continuation request pending with no first stream event;
  • retry/fallback in progress;
  • context compaction;
  • response received but awaiting persistence/rendering;
  • stale turn with no active work.

A watchdog should eventually retry, surface a recoverable error, or terminate the turn instead of requiring manual interruption.

The newer Windows/runtime/model combination suggests that the problem reported here is not limited to the original macOS 0.133.0 / gpt-5.5 environment.

mirnet-official · 1 month ago

Additional Windows reproduction from a ChatGPT Plus user.

Symptom
Codex Desktop repeatedly gets stuck indefinitely on Thinking during a local Android/ADB automation task. In some runs, previous tool calls complete and the UI never resumes. In other runs, the follow-up prompt is accepted but no tool call, shell command, progress trace, or final answer appears for 5+ minutes.

Important comparison
The same project and task work normally when Codex is used through Cursor on the same machine/account. This strongly suggests a Codex Desktop turn-state / streaming / renderer issue rather than a project, ADB, TikTok, device, or network problem.

Observed behavior

  • Windows desktop app
  • UI remains on Thinking
  • no approval dialog is waiting
  • no new command is started
  • the already-running external video/app continues independently, which can make it look like the automation is active even though Codex has stopped progressing
  • stopping/restarting the turn or opening a new task is often required
  • the issue has reproduced multiple times in the same project

Expected behavior
The desktop client should distinguish model reasoning, context compaction, a hung /responses stream, and a stale turn runner. It should also apply a watchdog/retry or surface an actionable error instead of remaining on Thinking indefinitely.

Related evidence appears consistent with this issue and with the broader Desktop turn-state problems discussed in #25779. Screenshots are available if useful.

Enping-Hu · 1 month ago

Codex Desktop: 26.721.41059
embedded codex: 0.146.0-alpha.3.1
model_provider: custom
wire_api: responses
model: gpt-5.6-sol / gpt-5.6-terra
behavior: tool completes successfully, then no assistant/tool events for 2–4 minutes; manual interrupt + “continue” immediately resumes

yxlphobe-pixel · 8 days ago

Additional macOS reproduction: 97-minute stall after a completed tool result and persisted token_count

I observed what appears to be the same post-tool continuation failure on a newer macOS Desktop runtime. This reproduction narrows the local failure boundary because the yielded background cell was explicitly awaited to completion, a subsequent standalone command also completed, and the final rollout event before the silent interval was token_count.

Environment

  • Product: Codex Desktop
  • Currently installed app bundle: 26.803.61601 (build 6396). This is the currently installed version and was not independently verified as the exact historical build at the time of the incident.
  • Embedded runtime recorded by the affected rollout: codex-cli 0.147.0-alpha.6.5
  • Model: gpt-5.6-sol
  • Reasoning effort: xhigh
  • Platform: Darwin 24.5.0 arm64 arm
  • Thread ID: 01a01944-f25e-7683-999d-ec90383c44ef
  • Affected turn ID: 01a01947-465f-7f20-ba48-7e6e6b87cbb6

Observed behavior

The agent was completing the final validation of a long Markdown research report.

  1. A parallel validation call temporarily yielded Script running with cell ID 73.
  2. The agent correctly called wait(cell_id=73), which returned Script completed with the expected output.
  3. The agent then issued a standalone wc -l -c command.
  4. That command completed successfully and returned 759 lines and 72,727 bytes.
  5. A token_count event was persisted immediately afterward.
  6. No reasoning, assistant message, tool call, error, timeout, compaction, or task_complete event followed for approximately 97 minutes 28 seconds.
  7. The UI continued to present the turn as active until I manually interrupted it.

Sanitized timeline (Asia/Singapore, UTC+8):

17:42:14.407  Outer exec yielded: Script running with cell ID 73
17:42:25.430  wait(cell_id=73) returned: Script completed
17:42:43.711  Standalone wc validation started
17:42:46.147  wc returned successfully: 759 lines, 72,727 bytes
17:42:46.156  token_count persisted
               [no further turn progress events for approximately 97m28s]
19:20:14.505  turn_aborted(reason=interrupted) after manual stop