[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 +