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.