[Windows Desktop][GPT-5.6 Sol] Turn stays running indefinitely after a successful tool result with no post-tool continuation

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

• #32555
• #32366

Powered by Codex Action

I am experiencing what appears to be the same issue on the Codex Windows Desktop app.

In my case:

• The task was performing a deep code review using GPT-5.6 Sol with high reasoning.
• The last visible tool call was a broad rg -n repository search.
• The ripgrep command returned a large amount of output successfully.
• Get-Process rg -ErrorAction SilentlyContinue returned no process, confirming that rg.exe had already exited.
• The UI remained in the running state for approximately 38 minutes.
• There was no subsequent reasoning event, tool call, completion, timeout, or visible error.
• Restarting the app and switching models did not prevent the issue from recurring multiple times during the same afternoon.
• logs_2.sqlite and logs_2.sqlite-wal did not grow while the task appeared stuck.

This strongly resembles a missing post-tool continuation rather than a slow or hung local command.

Environment:

• Windows Desktop app
• Local Windows workspace
• GPT-5.6 Sol, high reasoning
• Multi-step project analysis/code review task

I have additional evidence from 2026-07-13 and 2026-07-14. The issue is no longer limited to the original long thread; I observed the same pattern across multiple Codex Desktop windows/threads and at least two local workspaces on Windows.

Current affected Codex Desktop package: 26.707.62119.

I inspected local rollout JSONL records from 15 rollout files under sessions/2026/07/13 and sessions/2026/07/14. There were 28 event gaps longer than 15 minutes. Some of those were ordinary idle periods after completed tasks, but several were clean post-tool stalls ending only when I manually aborted the turn.

Clean samples, all times in CST:

| Time | Thread / turn | Last effective event before stall | Tool result | Silent interval until manual abort |
|---|---|---|---|---:|
| 2026-07-13 11:08:13 -> 12:29:24 | thread 019f5942-5546-7a60-ae2b-b9164bc13bcf, turn 019f5961-ce9d-7b70-b56c-bcfa7a9bd0be | custom_tool_call_output | command completed in 0.2s, output {} | 81.2m |
| 2026-07-13 11:13:23 -> 12:24:45 | thread 019f5942-5546-7a60-ae2b-b9164bc13bcf, turn 019f595e-9978-76f0-a2f1-32af8be0b3ab | custom_tool_call_output | command completed in 0.1s, output {} | 71.4m |
| 2026-07-14 10:16:23 -> 10:35:03 | thread 019f5e47-420d-7021-a6d8-0f115e34474e, turn 019f5e67-8d5a-7360-bdfe-7f8b3bae9b19 | custom_tool_call_output | command completed in 0.8s with a large/truncated skill-read output | 18.7m |
| 2026-07-14 12:09:52 -> 12:39:37 | thread 019f5e47-420d-7021-a6d8-0f115e34474e, turn 019f5ec8-73e8-7932-a7b2-8a93e7385738 | custom_tool_call_output | command completed in 0.5s and returned a PowerShell parser error | 29.7m |
| 2026-07-14 12:50:00 -> 13:07:24 | thread 019f5e47-420d-7021-a6d8-0f115e34474e, turn 019f5eef-4e26-7d32-abb7-866fb0e7bb71 | custom_tool_call_output | cleanup + smoke-check completed in 2.3s and returned validation JSON | 17.4m |

The 2026-07-14 12:50 sample is especially clean. The final tool output included:

Removed pycache directories: 2
{"ReportBytes":48935,"SourcesBytes":1201627,"HeadingDiffCount":0,"MarkdownImageRefs":8,"IpoImageWidth":1672,"IpoImageHeight":941,"PromptMentionsBarChart":true,"LegacyHeadingPresent":false}

After that tool result, there was no assistant continuation, no next tool call, no final response, and no visible timeout/error until manual abort.

Additional observations:

• The affected turns were using gpt-5.6-sol; local app logs show codex.turn.reasoning_effort=xhigh for the related activity.
• The failure is not limited to large output. I saw the same behavior after {}, after a short validation result, after a shell parser error, and after larger truncated output.
• The failure is not a hung local command. The tool completion time is recorded before the silent interval.
• The user-facing symptom is that Codex Desktop keeps the turn running indefinitely; normal prompting in the same turn does not help, and manual abort is required.

This makes the likely failure boundary look like post-tool continuation scheduling or post-tool response handling, rather than shell/tool execution itself.

Suggested mitigations:

• Add a watchdog after a tool result is recorded: if no next sampling request, assistant message, tool call, completion, or error appears within a bounded period, surface a recovery action or retry the continuation.
• Treat a model response that completes with no actionable output after a tool result as a retryable no-op, not as an indefinitely running turn.
• Expose the last completed tool call and timestamp in the UI, plus a "continue from last tool result" recovery action.
• Include last rollout event type, tool call id, thread id, turn id, and next sampling request id in telemetry so it is possible to distinguish "client did not schedule continuation" from "service request did not return" or "client dropped the response".

I am still not attaching raw logs or project content for privacy reasons, but the thread/turn identifiers above should be enough to locate the relevant telemetry internally.

+1 😢

Additional Windows Desktop occurrence with a more specific exec / nested-tool timing signal (originally reported as #33036):

• Codex Desktop package: 26.707.9981.0
• Windows x64 build: 10.0.26200
• A code-mode exec cell awaited a nested local shell_command configured with timeout_ms: 10000.
• The local command later reported exit code 0 and an actual wall time of about 0.2s.
• No model-visible continuation or progress arrived for about 3,806.8s.
• The outer cell then returned Script running with cell ID <redacted>.
• An immediate wait(cell_id=..., yield_time_ms=1000) reported the cell as already completed.

Sanitized timeline:

T+0s       exec starts nested local shell_command (timeout_ms=10000)
T+3806.8s exec finally yields "Script running with cell ID ..."
T+~3807s  wait returns immediately: completed; nested command exit=0, wall=0.2s

This supports the same user-visible failure described here: a successful local tool result does not produce a bounded post-tool continuation, error, or recovery path. It also suggests investigating the boundary between nested-tool completion, code-mode cell closure/yield, and turn-runner notification delivery.

No private paths, project content, account identifiers, or raw session logs are included.

Additional matching occurrence from the current Windows Desktop package, with a transport-level distinction:

• Codex / ChatGPT Desktop package: 26.707.9981.0
• Windows x64 build family: 10.0.26200
• Model: gpt-5.6-sol, Extra High
• Local Windows workspace, long-running thread
• A short read-only PowerShell diagnostic completed successfully in about 0.9s, and the outer exec cell reported completion.
• The turn then produced no user-visible assistant continuation and remained active until manual interruption/follow-up roughly ten minutes later.
• Desktop logs showed the local AppServerConnection remained established over stdio; there was no app-server disconnect/reconnect or connection error during the stall.
• The renderer repeatedly logged ResizeObserver loop completed with undelivered notifications, but I do not know whether that warning is causal.

This occurrence therefore does not look like a hung shell process or a local app-server transport disconnect. It is consistent with a failure or indefinite wait after tool completion at the post-tool continuation / turn-runner boundary.

No project names, local paths, transcript content, account identifiers, proxy details, or raw logs are included.

same but with cli +

New A/B reproduction on Windows 26.803.5235.0: nested tool completes, outer turn remains active

I reproduced the same post-tool continuation stall on the current Windows Desktop package, with a useful same-operation comparison and renderer timing.

Environment

• Codex Desktop package: OpenAI.Codex 26.803.5235.0
• Embedded app-server: 0.147.0-alpha.6.5
• Windows 11 x64
• Model: gpt-5.6-sol
• Reasoning effort: xhigh
• Local Windows thread
• No subagent, approval prompt, compiler, test suite, or long-running shell process was involved

Stalled occurrence

The operation was a short, read-only PowerShell fetch of the official Codex troubleshooting page, awaited by a code-mode exec cell.

Sanitized persisted timeline:

T+0s      nested command starts
T+~3s     custom_tool_call_output is persisted; command completed successfully
T+~3s     UI shows the inner command as completed in about 2s
T+~3s     outer tool/turn remains displayed as Running
T+93s     user manually interrupts

Between the persisted tool output and the interrupt, the rollout contained no subsequent:

• agent_reasoning
• assistant message
• tool call
• task_complete
• visible error

The app-server remained responsive. At interruption time, Desktop logged:

• turn/interrupt: 11 ms
• immediately following thread/list: 1 ms
• no app-server unavailable/disconnect marker
• no matching Windows crash, OOM, or resource-exhaustion event

The primary renderer logged 71 instances of:

ResizeObserver loop completed with undelivered notifications.

during the 90-second silent interval. The UI simultaneously showed an outer “Running” tool card while the nested command card already showed successful completion.

Same-operation successful comparison

In the next turn, I ran the equivalent official-document fetch again:

T+0s    tool result persisted
T+7s    agent reasoning resumed
T+7s    a commentary message was emitted

That successful interval had 17 ResizeObserver errors rather than 71. This does not prove the ResizeObserver loop is causal, but it provides a correlated renderer signal and confirms the tool type/URL itself is not deterministically hanging.

Diagnostic boundary

This sample still cannot distinguish:

1. no post-tool continuation request was dispatched;
2. a continuation request was dispatched but produced no first stream event; or
3. the turn runner received no actionable continuation and failed to terminalize.

Useful telemetry would record, after custom_tool_call_output:

• continuation request dispatch timestamp and request ID;
• time to first streamed event;
• retry/fallback state;
• outer code-mode cell closure/yield;
• renderer transition from nested-tool completion to outer-turn state;
• a bounded watchdog/recovery action when none of those transitions occur.

Immediate repeat with a minimized command

I reproduced the same boundary again with this short read-only command:

$index=(Invoke-WebRequest -UseBasicParsing -Uri 'https://developers.openai.com/llms.txt' -TimeoutSec 20).Content

In this occurrence:

• the inner command completed successfully in about 3.4 seconds and returned its tool result;
• the outer tool card still displayed Running;
• no post-tool assistant continuation became visible;
• the turn had been processing for 3 minutes 19 seconds when it was manually interrupted.

The same command has also completed and resumed normally in another occurrence, so it is a useful intermittent trigger, not evidence that Invoke-WebRequest, the URL, or the network request is itself the root cause. The more precise failure boundary remains: inner command completes → tool result is returned → post-tool continuation does not arrive promptly → outer tool card remains Running.

All thread IDs, turn IDs, paths, prompts, command output, account data, raw logs, and screenshots are intentionally omitted.

Additional reproductions — fresh-session, medium-reasoning, and 15.5h stall

Adding three independent reproductions that match this issue's signature closely: a tool call returns and its result is persisted, but the turn never proceeds to the next model step. No visible error, timeout event, or exception is emitted; the turn remains active until it is manually interrupted and a new message is sent.

• Environment: Codex Desktop build 26.803.81509, Windows 10, model gpt-5.6-sol, model_reasoning_effort = medium, wire_api = responses, custom provider.
• In all three cases, the stall is per-turn / per-conversation. Newly opened conversations remain functional while the affected conversation is stalled. This argues strongly against a global provider/config failure and is consistent with a per-turn continuation bug.
• Recovery in all observed cases: interrupt the running turn (turn_aborted, reason=interrupted) and send a new message. The thread then resumes normally.
• Waiting has not been a useful recovery strategy. In the most severe case, the turn remained stalled for approximately 15.5 hours with no automatic recovery.

---

Case C — 15.5-hour stall with no auto-recovery (2026-08-12)

• Thread: 019ff559-870a-79d1-a702-d0a3738b022d
• Turn: 019ff579-6577-7d32-9525-ad740b3437e8
• The agent was executing a sequence of exec tool calls. After an exec result was returned and persisted, the turn stopped making progress and did not recover until manually interrupted the following day.

Event chain (timestamps UTC):

| Time (UTC) | Event |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| 10:16:41 | Turn started (started_at=1786529801) |
| 10:31:21.913 | custom_tool_call_output (exec) → "Script completed, Wall time …" + token_count |
| 10:31:34.071 | agent_reasoning |
| 10:31:34.414 | custom_tool_call exec |
| 10:31:40.201 | custom_tool_call_output → "Script failed, Wall time 5.x seconds" + token_count |
| 10:32:44.695 | custom_tool_call exec + patch_apply_end |
| 10:32:44.858 | custom_tool_call_output → "Script completed" + token_count |
| 10:33:05.455 | custom_tool_call_output (exec) → "Script running with cell ID 66, Wall time 11.0 seconds" |
| 10:33:05.459 | event_msg token_count |
| — | Silence for 55,664,453 ms (≈15 h 28 min). No agent_reasoning, no reasoning, no follow-up tool call, no visible error, and no timeout event. |
| 2026-08-13 01:44:25.923 | turn_aborted, reason=interrupted, duration_ms=55664453 — manual interrupt |

The exec tool returned a valid tool result and token_count was emitted, but the agent never scheduled any follow-up action for more than 15 hours — no additional reasoning, no wait/poll of the returned cell, no subsequent tool call, and no completion/error event.

Regardless of the underlying cell state, the turn itself stopped making progress and did not self-recover.

---

Case A — Stall after a wait_agent result (2026-08-13)

• Thread: 019ffa76-d3e0-7711-a413-982c92e2b08e
• The parent agent was operating in multi-agent mode. It spawned a sub-agent and then called wait_agent twice. Both waits returned normally with timeout results. After the second function_call_output was persisted, the parent turn never continued.

Event chain (timestamps UTC, from the rollout JSONL):

| Time (UTC) | Event |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 10:50:18.742 | function_call spawn_agent |
| 10:50:26.756 | function_call wait_agent, arguments={"timeout_ms":20000} |
| 10:50:46.772 | function_call_output → {"message":"Wait timed out.","timed_out":true} |
| 10:50:53.130 | function_call wait_agent, arguments={"timeout_ms":30000} |
| 10:51:23.151 | function_call_output → {"message":"Wait timed out.","timed_out":true} |
| 10:51:23.159 | event_msg token_count |
| — | No further events. No agent_reasoning, no reasoning, no next tool call, no task_complete, and no turn_aborted. The rollout file ends here. |

The parent received a normal function_call_output from wait_agent, but no post-tool continuation was emitted afterward.

---

Case B — Stall after a plain exec result on the first message of a fresh session (2026-08-17)

• Thread: 01a00ea9-9d8e-7643-9753-f0cbaa2a6812
• Turn: 01a00ea9-a9f7-7493-afb4-cb6a8e104732
• This case is not sub-agent related. The agent invoked the normal shell exec tool, which completed successfully in approximately 0.9 seconds. The turn then stalled immediately afterward.

Event chain (timestamps UTC, from the rollout JSONL):

| Time (UTC) | Event |
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
| 07:39:55.410 | session_meta / task_started — turn begins |
| 07:39:56.443 | user_message — first message of this session |
| 07:40:01.146 | agent_reasoning |
| 07:40:02.179 | agent_message |
| 07:40:03.055 | custom_tool_call exec |
| 07:40:04.022 | custom_tool_call_output → "Script completed\nWall time 0.9 seconds" |
| 07:40:04.022 | event_msg token_count |
| — | Silence for 1,120,804 ms (≈18 min 41 s). No agent_reasoning, no reasoning, no next tool call, no visible error, and no timeout event. |
| 07:58:36.072 | turn_aborted, reason=interrupted, duration_ms=1120804 — manual interrupt |

After the interrupt, sending a new "redo" message resumed the thread normally.

This occurrence is notable because the stall happened on the first user message of a fresh session. Therefore, a very large context window or many previous auto-compactions are not required to reproduce the issue, although they may still affect the probability of occurrence.

Recurrence after recovery

Approximately 22 minutes after the interrupt-and-resume recovery, the same thread stalled again.

The later turn produced the same signature:

• exec returned "Script completed, Wall time 10.2 seconds";
• event_msg token_count was emitted at 08:49:07.480Z;
• no subsequent reasoning, tool call, completion, error, or timeout event appeared;
• the turn remained stalled for more than 21 minutes at the time it was inspected.

This indicates that interrupt + resume recovers the currently stuck turn, but does not prevent the failure from recurring later in the same thread.

---

Shared signature

Across these reproductions:

1. A tool call returns and its output is persisted as function_call_output or custom_tool_call_output.
2. A token_count event is emitted.
3. The expected post-tool continuation does not appear:

• no agent_reasoning;
• no reasoning;
• no next tool call;
• no task_complete;
• no visible error or timeout.

1. The affected turn remains active indefinitely until manually interrupted.
2. A manual interrupt followed by a new user message restores the thread, but the issue may recur later.

---

What I could rule out

• Not a provider-side streaming/network stall. I verified directly from the custom provider's server-side request logs that no subsequent model request was received after the tool result. Combined with the local rollout ending at function_call_output / custom_tool_call_output followed by token_count, this strongly indicates that the post-tool continuation request was never dispatched to the provider, rather than a request being sent and then hanging mid-stream.

• Not a global provider/config failure. While one conversation is stalled, newly opened conversations in the same Codex Desktop instance, using the same provider and configuration, continue to send requests and operate normally.

• Not specific to one tool type. I reproduced the same failure after both wait_agent (function_call_output) and a normal shell exec (custom_tool_call_output).

• Not dependent on a long-running or heavily compacted thread. Case B reproduced on the first user message of a fresh session.

---

Reproduction / detection hint

The issue is intermittent, but the cleanest local signal is:

A tool result is persisted (function_call_output / custom_tool_call_output), followed by token_count, and then no new rollout events appear while the UI continues to show the turn as running.

In my reproductions, waiting did not cause the turn to recover, including one occurrence lasting approximately 15.5 hours.

At present, the only reliable recovery I have found is:

1. manually interrupt the stuck turn;
2. send a new message such as "继续";
3. allow the thread to resume from the already-completed work.

Happy to provide additional sanitized rollout JSONL excerpts or timestamps if useful.