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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   tool-callsIssues related to tool callingIssues related to tool calling

   on Jul 13, 2026
2. github-actions commented on Jul 13, 2026

   

   github-actionsbot

   on Jul 13, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • # Codex Desktop turn stays in “Thinking” after WebSocket stream disconnects with Broken pipe #32555
   • Codex Desktop stalls on an existing long-running thread: WebSocket closes before response.completed, while HTTP fallback returns 200 OK but produces no stream events #32366

   Powered by Codex Action
3. QXUAN commented on Jul 13, 2026

   

   QXUAN

   on Jul 13, 2026

   More actions

   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
4. QXUAN

   marked Codex Windows app repeatedly gets stuck after a completed ripgrep command #32750 as a duplicate of this issue on Jul 13, 2026
5. Luohui1981 commented on Jul 14, 2026

   

   Luohui1981

   on Jul 14, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   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.

   👍React with 👍2Reacted by stkman and Ocheron
6. dlpuzhangyue commented on Jul 14, 2026

   

   dlpuzhangyue

   on Jul 14, 2026

   More actions

   +1 😢
7. Sirius19930603 commented on Jul 14, 2026

   

   Sirius19930603

   on Jul 14, 2026 – with ChatGPT Codex Connector

   More actions

   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.

   👍React with 👍1Reacted by Ocheron
8. hewzhew commented on Jul 14, 2026

   

   hewzhew

   on Jul 14, 2026 – with ChatGPT Codex Connector

   More actions

   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.
9. ham-zax commented on Jul 14, 2026

   

   ham-zax

   on Jul 14, 2026

   More actions

   same but with cli +
10. hewzhew commented on Aug 10, 2026

    

    hewzhew

    on Aug 10, 2026 – with ChatGPT Codex Connector

    Last edited by hewzhew

    More actions

    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.
11. a1m67 commented on Aug 17, 2026

    

    a1m67

    on Aug 17, 2026

    Last edited by a1m67

    More actions

    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 "ncotinue" 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.

    4. The affected turn remains active indefinitely until manually interrupted.

    5. 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 "cotinue";
    3. allow the thread to resume from the already-completed work.

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

    👍React with 👍1Reacted by a1m67
12. guiguiluo commented on Aug 28, 2026

    

    guiguiluo

    on Aug 28, 2026 – with ChatGPT Codex Connector

    More actions

    Cross-surface reproduction on ChatGPT Web — steering the still-running turn temporarily wakes it, then it stalls again

    I am seeing what appears to be the same post-tool continuation failure on ChatGPT Web, not Codex Desktop.

    Environment

    • Surface: ChatGPT Web
    • Subscription: ChatGPT Pro
    • Model selection: Pro
    • OS: Windows 10 x64
    • Browser: Microsoft Edge 151
    • Date observed: 2026-08-28

    Observed behavior

    This happens during a long multi-step mathematical modeling task that uses the built-in Python tool repeatedly.

    The failure pattern is very consistent:

    1. The model performs several reasoning/tool steps normally.
    2. A Python call completes successfully and its result is visibly returned in the Activity panel.
    3. After the tool result, there is no next reasoning step, no next tool call, no final answer, and no visible error.
    4. The UI continues to show the task as Thinking / running indefinitely. In one occurrence the Activity timer reached about 17m 32s with no progress after the completed Python result.
    5. Crucially, I do not press Stop / abort the active turn. While it is still shown as running, I insert a new user message into the active task (for example asking it to continue).
    6. That steering message is accepted and the model immediately becomes responsive again: it continues reasoning and may execute several more Python/tool steps.
    7. After a few steps, the exact same failure recurs: a Python result is returned successfully, then automatic continuation stops again while the UI remains in the running state.
    8. Another inserted user message can wake it again. This can repeat multiple times in the same task.

    So this is not just a stale spinner after a completed turn, and it is not a hung Python execution: the Python result is already present before the stall, and the still-running task can be temporarily revived by a user steer without aborting it.

    Why this reproduction may be diagnostically useful

    The distinctive sequence is:

    assistant reasoning
      -> Python/tool call
      -> tool result returned successfully
      -> no automatic post-tool continuation
      -> task remains marked running
      -> user steer/message is inserted WITHOUT aborting
      -> model continues again
      -> a few steps later another successful tool result
      -> post-tool continuation stalls again
    

    This makes the failure look more like a missing/failed automatic continuation or wake/scheduling transition after tool completion than a tool process that is still running.

    The fact that a new user steer can revive the same still-running task may help distinguish this from cases where the model request itself is permanently dead or the UI is only visually stale.

    Expected behavior

    After Python/tool output is returned, the task should automatically continue to the next reasoning/model step.

    If the post-tool continuation fails to start or returns no events, ChatGPT should detect that condition and either safely retry, surface an actionable error/recovery control, or explicitly transition out of the running state. A user should not need to repeatedly send manual “continue” messages every few tool calls to keep a Pro task alive.

    Impact

    For long Pro tasks using Python, this currently makes autonomous multi-step execution unreliable: the task can progress only a few steps at a time before requiring another manual kick.

    I have a screenshot showing the Activity panel with completed Python output followed by a long-running stall and can provide additional session/feedback identifiers privately if maintainers need them.
13. firecrauter commented on Sep 1, 2026

    

    firecrauter

    on Sep 1, 2026

    Last edited by firecrauter

    More actions

    I encountered what appears to be the same failure mode described in this issue. I cannot currently claim deterministic reproduction because I completed the original task using a workaround, the project state has since changed, and rerunning the same prompt would not be an equivalent test.

    In-app feedback

    • Feedback ID: 01a05b1e-aa7a-77a2-a50d-0db7e0101234
    • Feedback was submitted from the affected task with session logs included.
    • Affected task/thread ID: 01a05b1e-aa7a-77a2-a50d-0db7e0101234

    Environment

    • Codex Desktop for Windows: 26.825.6671.0
    • Model: gpt-5.6-sol
    • Reasoning effort for the documented occurrence: xhigh

    I have also encountered similar stalls with Sol at Max reasoning effort, although the detailed timings below are from the xhigh occurrence.

    Observed behavior

    Initial attempt

    Turn ID: 01a05b1e-e7b1-75b0-8c81-519a40e1b897

    • Five tool calls returned and their outputs were persisted.
    • No tool remained running.
    • After the final reasoning/commentary event, there were no further model, reasoning, tool, completion, or explicit error events for approximately 258.6 seconds.
    • I manually interrupted the task.

    Follow-up attempt

    Turn ID: 01a05b23-d1e6-7041-9ef3-0ea1f0487348

    • I sent the follow-up message continua.
    • Codex emitted one reasoning item and one commentary message.
    • It did not make another tool call or produce a completion.
    • It remained silent for approximately 262 seconds until I manually interrupted it again.

    The available session metadata does not show a tool remaining active. This looks more like a missing model continuation after tool results than a hung shell command.

    Earlier occurrence

    I experienced a similar problem several weeks earlier. After approximately 3–7 reasoning/toolchain steps, Codex could remain stuck for up to 30 minutes, attempt to reconnect, and then become stuck again.

    That older reconnect behavior may also be related to #23807.

    Workarounds

    The following workarounds helped me:

    1. Ask Codex to first produce a step-by-step implementation plan, then send a separate prompt asking it to implement the plan.
    2. Switch from GPT-5.6 Sol to GPT-5.6 Terra.

    For the same underlying task, the plan-first approach allowed Codex to finish successfully. However, because the task is now completed and its project state has changed, I cannot faithfully rerun the original prompt to determine whether the failure is consistently reproducible.

    Related public report

    Another user described a exact similar “thinking loop” behavior on Reddit:
    " Codex stuck in a 5-step "thinking" loop every single prompt "
    https://www.reddit.com/r/OpenaiCodex/comments/1w24mxa/codex_stuck_in_a_5step_thinking_loop_every_single/

    

    Expected behavior

    After receiving tool results, Codex should either continue reasoning/execution, complete the task, or return an explicit actionable error instead of remaining active without further events.

    AI assistance disclosure

    This comment was drafted with AI assistance using my description and local Codex session metadata. I reviewed it before posting and confirm that it accurately represents what I observed.
14. frank199123 commented on Oct 6, 2026

    

    frank199123

    on Oct 6, 2026

    More actions

    If Codex is still spinning after about five turns, that is this bug. You can use the Antigravity app to fix it: open the Codex project in Google Antigravity and have it repair the stall after a successful tool result.