Codex Desktop crashes entire application due to missing tool call result

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

• #31113

Powered by Codex Action

When I had 5.6 Terra investigate this, it attempted to back-patch in a missing tool call so that it wouldn't fail, which instead led to the following issue occurring when I attempted to reopen the thread:

(code=3221225786, signal=null).
Most recent error: {"timestamp":"2026-07-12T22:44:11.844541Z","level":"WARN","fields":{"message":"ignored world-state patch without a full snapshot"},"target":"codex_core::session::rollout_reconstruction"}

Despite this being a "WARN" level it still _crashed the entire application_.

and this one too now. it's whackamole. these things are only happening after this recent update. I'm going to try to downgrade at this point.

(code=3221225786, signal=null).
Most recent error: {"timestamp":"2026-07-12T22:55:35.033836Z","level":"WARN","fields":{"message":"Model personality requested but model_messages is missing, falling back to base instructions.","model":"gpt-5.6-sol","personality":"friendly"},"target":"codex_protocol::openai_models"}

Independent Windows Desktop reproduction with a closely matching failure signature.

Environment

• Windows 11 x64
• Codex Desktop: 26.707.8168.0
• Bundled runtime: codex-cli 0.144.0-alpha.4
• Model: gpt-5.6-sol
• Reasoning effort: ultra
• Configured personality: none (also tested with the personality feature disabled)

Visible failure

The Desktop error screen reports:

(code=4294967295, signal=null)

The most recent visible log entry is:

Model personality requested but model_messages is missing, falling back to base instructions.
model=gpt-5.6-sol personality=friendly

However, the structured backend log shows a more specific boundary immediately before the worker disappears:

Output item item=CustomToolCall {
  status: Some("in_progress"),
  name: "exec",
  input: ""
}

No completed custom-tool input or tool output follows. The native codex.exe worker exits abruptly, while the Desktop process remains alive and starts a replacement worker. The existing task can continue after recovery/reload. I observed this pattern more than once.

An isolated gpt-5.5 shell-tool smoke test succeeds on the same machine and authentication, which points away from the shell, permissions, or repository itself. The failure is specific to the GPT-5.6 custom exec transition on this installation.

This appears related to:

• #32659 — app-server stream stops at CustomToolCall(status=in_progress, input="")
• #32013 — Windows + gpt-5.6-sol + personality fallback + recoverable process-unavailable state
• #30861 — GPT-5.6 shell/tool transition crash on another platform

The personality message may only be the last warning surfaced by the crash screen rather than the actual fatal condition. A guard that treats an incomplete custom-tool item as a recoverable stream error—and reconnects/retries instead of terminating the worker—would prevent the whole Desktop failure.

Local paths, task contents, and call IDs have been redacted.

Independent Windows Desktop reproduction with persisted-rollout evidence.

Environment

• Windows 11 x64
• Codex Desktop 26.707.8479.0
• Bundled app-server 0.144.2
• Standalone CLI 0.144.1
• [features].unified_exec=false
• 13.51 GB RAM available at the time of capture

Fatal event

(code=3221225786, signal=null)
2026-07-14T01:44:42.152096Z ERROR codex_core::util
Custom tool call output is missing for call id: call_xo0N1LgFxaTxxKYhwdsO4DZA

Focused reproduction

The persisted rollout contains an exec custom-tool call recorded at 2026-07-13T06:57:29Z with no matching tool-call output. It was a harmless container-status query. Desktop resumed that task at 2026-07-14T01:44:30Z, started a new turn at 01:44:38Z, and app-server failed on the stale unpaired call at 01:44:42Z. Desktop observed process exit at 01:44:53Z and initialized a replacement app-server successfully at 01:44:57Z.

The affected rollout had 616 tool calls and 612 outputs; four calls were unpaired, including the fatal stale call and the new call interrupted by this crash. At least three concurrent task streams were active in the focused crash window, so termination of the shared app-server interrupted all of them.

The same Desktop build also logged another Custom tool call output is missing fatal event at 2026-07-13T11:21:46Z for a different call ID. This is separate from a previously mitigated Windows unified_exec/stale-process failure.

This points to persisted incomplete tool-call history being replayed on task resume. A missing tool result should interrupt only the affected turn or be represented as a recoverable failed result; it should not terminate the shared app-server and every active task.

I did not modify or back-patch the rollout because the earlier report here notes that doing so can trigger another fatal rollout-reconstruction error. Local paths, task contents, commands beyond their harmless category, and credentials are omitted.

Additional Windows desktop evidence (no prompt, project, or session contents included):

Environment

• Windows 11 / build 26200, x64; native PowerShell agent. WSL is not installed.
• Codex desktop AppX: 26.707.8168.0 at initial inspection; it auto-updated during investigation to 26.707.9564.0.
• Bundled Codex CLI previously reported 0.144.0-alpha.4.
• config.toml parses successfully (codex mcp list succeeds), and Microsoft Store/winget reported no manual upgrade available before the in-place AppX update.

Observed failure

• Confirmed fatal dialog: code=3221225786, signal=null at 2026-07-13T19:14:41.978845Z.
• The preceding custom exec call, call_TxIyvHyslfmwG4sYFzfVM3bO, was recorded at 2026-07-13T19:06:19Z, but there is no matching custom_tool_call_output event in the local transcript.
• In the 2026-07-12 through 2026-07-14 local session data, 21 of 780 custom exec calls have no matching output event (2.69%). At least the call above is confirmed to have culminated in the crash dialog; the remaining unmatched events are transcript anomalies and should not all be assumed to be crashes.

Likely mechanism
The event order matches the persisted-rollout replay mechanism described in comment #4964649683: an incomplete custom-tool call remains in the rollout, and the shared app-server terminates when a later task/session resume tries to reconcile it. Locally, the unmatched call above was followed by a new task start about 7.98 minutes later, immediately before the fatal window.

Why long instructions appear to trigger it
The data does not show an input-size threshold. The unmatched calls occurred after instructions ranging from 28 to 4,111 characters, and their tool payloads were small (mostly 330–566 characters; one was 2,191). The stronger correlation is tool-heavy/long-lived work: more tool calls create more chances for the custom-tool result bookkeeping to lose an output event, which then persists into a later resume. This aligns with the long tool-heavy pattern reported in #14824.

Update-state observation
After the automatic AppX update, the persisted user config still contained app-generated references to the prior runtime binaries, which were no longer present. This may be secondary, but it indicates that an in-place desktop update can leave stale tool-runtime references while a session is active.

Expected behavior: a missing or failed tool result should be surfaced as a recoverable tool failure (or retried), not crash the entire desktop application or interrupt every active task.

I can provide sanitized event timestamps/call IDs if maintainers need them.

Independent reproduction on a newer Windows Desktop build, with one additional failure mode that may help narrow this down.

Environment

• Windows 11 x64
• Codex Desktop AppX: 26.707.9981.0
• Native PowerShell
• config.toml parses successfully with Python tomllib

Reproduction 1: missing output after a trivial exec

This has occurred in multiple unrelated tasks. In one focused case, the custom tool call was only:

git status --short; git diff --check; git diff --stat

The call was persisted at 2026-07-14T07:56:24.504Z, but no matching custom_tool_call_output was stored before a new turn began at 07:57:08.549Z. Reopening/resuming the affected task then produced:

(code=3221225786, signal=null)
Custom tool call output is missing for call id: <redacted>

This shows the problem is not limited to long-running or high-output commands.

Reproduction 2: normal apply_patch rejection also crashed Desktop

At 2026-07-14T12:33:58.397Z, an apply_patch call targeted lines that had already changed. At 12:33:58.459Z, the rollout correctly stored a matching custom_tool_call_output containing:

apply_patch verification failed: Failed to find expected lines ...

That is a normal, recoverable patch-context mismatch. However, Desktop still showed the whole-app crash dialog with code=3221225786, using that tool error as the most recent error.

This may be a related error-propagation path rather than the exact missing-output path, but both turn ordinary tool failures into shared app-server termination.

Mitigations already tried

• Verified that the active TOML config is valid.
• Avoided write_stdin and all control-character interrupts in subsequent reproductions.
• Ran tests and commands serially.
• Started new tasks instead of reopening known-corrupted tasks.
• Reduced optional helpers/plugins.

The issue still reproduced on short commands and on an expected apply_patch verification failure.

Impact

Several unrelated tasks became unsafe to reopen and had to be archived, while all active work was interrupted when the shared app-server exited. This is severely disruptive for normal coding work.

Expected behavior: persist an explicit aborted/error output atomically when a turn is superseded or a tool fails; if a historical call is unpaired, recover or quarantine only that turn/task. A normal tool failure or stale task record should never terminate the shared app-server.

Local paths, task contents, and call IDs are omitted. Sanitized event excerpts can be provided if needed.

Correction / withdrawal

I am withdrawing the conclusion in my previous comment that the nested approval boundary was the cause of my reproduction.

Follow-up investigation found a deterministic local trigger in the project under test: Python code called os.kill(pid, 0) as a PID-liveness probe. That is a POSIX idiom but is unsafe on Windows. In CPython on Windows, signal value 0 collides with CTRL_C_EVENT and is routed through GenerateConsoleCtrlEvent. When run inside Code Mode, the resulting console control event can interrupt the tool process and the App Server sharing that console/control domain, producing 0xC000013A / STATUS_CONTROL_C_EXIT and leaving an unmatched custom tool call.

After replacing the Windows probe with OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) plus GetExitCodeProcess, the complete test suite finished successfully (57 passed) without an App Server restart.

Please disregard my earlier comment as evidence that approval escalation itself caused these exits. This correction applies to my reproduction only; it does not invalidate the issue author's report or the independent reproductions above.

Windows warning: do not use os.kill(pid, 0) as a process-existence check. Use a Windows-specific non-signaling process query or an OS-backed lock instead.

Current macOS evidence — Desktop 26.803.61601

A read-only aggregate of the current structured log found 181 messages matching the missing-tool-output error class between approximately 23:58 and 02:30 UTC during concurrent tool-heavy tasks.

Environment: macOS arm64, Codex Desktop 26.803.61601, bundled CLI 0.147.0-alpha.6.5.

No whole-app crash was observed during this audit, so this comment does not claim the same crash outcome as the original Windows report. It confirms that missing tool-call results still occur at high volume in a current desktop build and can affect many turns. Call IDs, task IDs, prompts, paths, account data, and raw logs are omitted.

I’m testing Codex Rescue 0.1.0a3 against real broken-session cases, and the persisted missing-tool-output boundary here is a direct match for one of its diagnostics.

Rescue can detect an unfinished/orphaned tool call from the rollout, preserve the original file unchanged, and create a bounded handoff. It does not back-patch or invent the missing tool result.

If you still have one affected rollout, would you be willing to try:

pipx install codex-rescue==0.1.0a3
codex-rescue doctor --latest

If it finds the affected session, sanitized doctor / salvage --fork / verify output would help validate this on a real Desktop crash case. Please don’t share the raw rollout, prompts, DBs, credentials, or private paths.

https://github.com/shleder/codex-rescue

Deterministic Windows MRE: abrupt child termination crashes Codex Desktop and corrupts the task transcript

Environment

• Windows 11 build 26200
• ChatGPT/Codex Desktop package: OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0
• Codex CLI: 0.149.0-alpha.4.1

Minimal reproduction

Run this as a Codex Desktop exec tool call on Windows:

python -c "import os; print('before', os.getpid()); os.kill(os.getpid(), 0); print('after')"

os.kill(pid, 0) is a POSIX liveness-probe idiom. In this Windows Python environment it terminates the child process instead of providing that probe. The abrupt child termination is the intentional trigger.

Expected

Codex Desktop remains open and records a terminal tool result (an ordinary failed/aborted exec result is sufficient). The task remains resumable.

Actual

Codex Desktop exits. The task JSONL contains a built-in custom_tool_call named exec without a matching custom_tool_call_output. Reopening or continuing the task can then immediately fail with:

Custom tool call output is missing for call id: <call-id>

Why this was found

My project used os.kill(pid, 0) to check a QA lease-owner PID. That made a pytest child terminate and deterministically triggered the Desktop failure. I replaced the Windows implementation with OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) and preserved the POSIX implementation on non-Windows systems. A fresh separate Desktop task then completed:

python -m pytest tests\test_qa_loop.py -q --maxfail=1

Result: 71 passed, 7 subtests passed; Desktop did not crash.

This avoids the trigger in my project, but the standalone MRE above still shows that Desktop must tolerate abrupt child-process termination and must not persist an orphaned tool call.

Impact / requested fix

Root-causing this, repairing affected task history, and eliminating the project trigger consumed approximately 10% of the weekly usage allowance on a $100 plan.

Please make interrupted or abruptly terminated tool calls persist a terminal error/aborted output, and make transcript recovery tolerate unresolved historical calls instead of terminating the app-server.

Independent Windows Desktop reproduction on a newer Store build. Same fatal class as this issue: persisted unpaired custom_tool_call becomes a shared app-server abort on resume.

Environment

• Windows 11 x64, build 26200
• Store package OpenAI.Codex 26.820.7780.0 (config/runtime still referenced 26.820.60940 immediately before this incident)
• Bundled CLI around 0.149.0-alpha.4 at thread start
• [features] unified_exec = false and shell_snapshot = false were already set
• [windows] sandbox = "elevated" kept (official Windows recommendation)

The config pin did not stop PTY tools.write_stdin(...) custom exec calls. Desktop still records those in rollouts.

Two-stage failure (this is the part that looks like “it was fine for a week”)

A new local thread (started after quarantining older poisoned rollouts) ran normally for ~7 days and grew a large tool-heavy rollout (~2k write_stdin execs).

Stage A — unpaired call is created (overnight, ~2026-08-27T04:55Z):
codex.exe exited 3221225786 (0xC000013A / STATUS_CONTROL_C_EXIT). Desktop log “most recent error” was an MCP shutdown warning (cloudflare-api OAuth refresh missing an authorization-server issuer). The Electron UI stayed up. The rollout kept a custom exec / write_stdin custom_tool_call with no matching custom_tool_call_output.

Stage B — resume makes it fatal (~2026-08-27T14:54–14:58Z):
On next use, Desktop auto-resumed that thread plus several other local threads (thread/resume). After a few minutes of continued work, app-server fatal-exited:

Custom tool call output is missing for call id: <redacted>
Codex CLI process exited classifiedAsExpected=false code=3221225786

That killed the shared app-server, so every other open thread dropped too. No Application Error 1000 / Hang 1002, no Crashpad dump. Rollout scan: 5212 custom tool calls / 5210 outputs (2 unpaired). A second unrelated local thread from the previous day already had 2 unpaired calls and would have been the next landmine.

Did not back-patch the JSONL (that path caused another fatal in earlier comments here). Recovery was Fully Quit, move only the affected rollout files out of sessions/, relaunch, continue in a new chat.

What this adds

1. Starting a new chat does not prevent this. Any long Windows thread that uses unified-exec/write_stdin can be poisoned by a later 0xC000013A death.
2. unified_exec = false in config.toml is not sufficient on current Desktop; the app still persists write_stdin execs.
3. Auto-resume of multiple threads on launch turns one poisoned rollout into a whole-app outage.
4. Expected: persist an aborted/error tool output atomically when the worker dies; on resume, treat unpaired historical calls as recoverable for that thread, not a fatal for the shared app-server.

No prompts, repo contents, local paths, or credentials included. Happy to provide sanitized timestamps if useful.

Related: #33136 (same exit code), #40231 (26.818+ Windows console-control regression still present on 26.820).