Repository navigation
[Windows] Codex Desktop app-server repeatedly restarts and loses tool call outputs #41236
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.820.80927
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64 (Windows 11)
What issue are you seeing?
Codex Desktop repeatedly terminates or restarts its app-server while an active task is executing tool calls. The UI is then reloaded or reset, and the active turn is left in an interrupted state.
This is not caused by a failing repository command. In the most recent occurrences, the PowerShell/Git/Python commands completed successfully, but the Codex backend terminated before attaching the tool result to the conversation history.
The local Codex logs contain the following direct error:
Custom tool call output is missing for call id
For the affected task, 2 out of approximately 337 exec tool calls are missing their corresponding recorded outputs. After reopening or resuming the task, Codex reconstructs the incomplete history, encounters the same missing tool output, and the interruption can repeat.
The problem has occurred in multiple Codex tasks since August 27, 2026. More than 90 occurrences of the same missing custom-tool-output error were recorded locally.
Windows Error Reporting and Crashpad contain no corresponding native crash dump. The machine also had approximately 179 GB of free memory, so this does not appear to be caused by memory pressure.
UI telemetry also reported state synchronization errors including:
Received turn/started for unknown conversation- streaming threads without an active runtime
This appears to be a Codex Desktop app-server/tool-call persistence or state synchronization bug, potentially amplified by resuming a long-running task with an incomplete tool-call record.
What steps can reproduce the bug?
Feedback ID: 01a041d5-1ee5-7842-a34a-cd3b6c899d8a
What is the expected behavior?
Codex should persist the completed tool result, attach it to the correct tool call, complete the active turn, and continue the task without restarting the app-server.
The app-server terminates during or immediately after a tool call. The command may finish successfully, but its result is not attached to the conversation history. The turn is left interrupted, and resuming the task can reproduce the same failure.
Additional information
Affected Codex thread ID:
01a041d5-1ee5-7842-a34a-cd3b6c899d8a
Feedback ID:
01a041d5-1ee5-7842-a34a-cd3b6c899d8a
One confirmed missing call:
call_Euw81SAf1P6CfscQKHQt5ZbX
Observed app versions:
- 26.820.60940
- 26.820.71523
- 26.820.80927
Current bundled CLI:
codex-cli 0.150.0-alpha.8
The issue occurred across multiple backend process restarts and multiple Codex tasks. No native Windows crash dump was generated.
Activity
github-actions commentedon Aug 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Anders0nAZ commentedon Sep 15, 2026
Reproduced again on September 15, 2026 across two newer Windows Desktop packages:
OpenAI.Codex_26.908.4834.0OpenAI.Codex_26.908.9136.00.154.0-alpha.6.2This produced 4 new dangling custom tool calls across the two most recent tasks (1/42 and 3/24 calls lacked outputs). An earlier original task had 6/186 missing outputs; two attempted forks also failed, including one on the inherited call ID.
The clearest new evidence is an update-time interruption:
The replacement package reproduced the same failure minutes later:
3221225786is0xC000013A(STATUS_CONTROL_C_EXIT). Other cases occurred immediately after approval/auto-review processing, but the exact component issuing the termination is not proven.Once a call is stranded, every follow-up dies before network submission at
run_turn.prepare_sampling_request_input. Automatic compaction hits the same error, and forks inherit it. The UI removes the submitted prompt and exposes no useful error.Full sanitized timeline, task/call IDs, rollout excerpts, and suggested safeguards:
codex-desktop-orphaned-tool-calls.md
Raw rollouts are not attached publicly because they contain private project prompts, source context, local paths, and telemetry. They can be provided privately to OpenAI if needed.