Windows Desktop Restart can orphan an in-flight custom tool call and poison task recovery

What version of the Codex App are you using?

• Microsoft Store/MSIX package: OpenAI.Codex 26.825.6671.0
• Bundled app-server reported by desktop logs: 0.151.0-alpha.7.2

What platform is your computer?

Windows x64

What issue are you seeing?

Pressing the visible Restart ChatGPT button while a code-mode custom tool call is in flight restarts only the child app-server and can leave the durable rollout ending in a custom_tool_call without a matching custom_tool_call_output.

That orphaned call can later trigger:

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

and the shared app-server exits with:

code=3221225786
hex=0xC000013A
classifiedAsExpected=false

The desktop then displays:

ChatGPT hit a snag
Something went wrong. Restart ChatGPT to try again.

This can affect every local task because the malformed task is projected by the shared app-server.

Steps to reproduce

1. Start a brand-new projectless Codex task.
2. Let it begin a code-mode exec custom tool call that runs long enough to remain in flight.
3. While the call is running, press the desktop error page's Restart ChatGPT button, or otherwise invoke that same desktop restart path.
4. Inspect the canonical paginated rollout after the replacement app-server starts.
5. Resume or reopen the affected task.

Captured deterministic evidence

Before restart, the clean task's canonical JSONL contained:

• 88 physical records
• top-level ordinals 0..87, strictly contiguous
• no duplicate ordinals
• 11 custom_tool_call records
• 10 matching custom_tool_call_output records
• exactly one unmatched call: the final record, ordinal 87

The final record was an exec call running a bounded unit-test command. The task did not import or copy any previous rollout.

The desktop log records the restart at the same boundary:

2026-09-01T08:35:49.964Z [AppServerConnection]
Restart requested hostId=local intent=restart killCodexProcess=false transportKind=stdio

2026-09-01T08:35:49.964Z [AppServerConnection]
Stopping app-server transport connectionId=6 transport=stdio

2026-09-01T08:35:49.965Z
app_server_connection.state_changed cause=stop_process
currentState=connected next=disconnected

2026-09-01T08:35:49.983Z [StdioConnection]
stdio_transport_spawned ... codex.exe pid=<redacted>

2026-09-01T08:35:50.060Z
Current reported app-server version: 0.151.0-alpha.7.2

After restart, the rollout still ended at the completed custom_tool_call and never received a matching output or durable interruption record.

This distinguishes the issue from an inherited corrupt transcript: the new rollout had valid consecutive ordinals until the restart interrupted the active call.

Expected behavior

An intentional desktop restart should atomically do one of the following before stopping app-server:

• wait for active tool calls to finish;
• cancel them and persist a supported interruption result;
• or mark the active turn interrupted so resume can safely continue.

A trailing tool call without output should be recoverable and isolated to that task. It should not terminate the shared app-server or display a global fatal page.

Requested regression coverage

Please add tests for:

1. desktop restart while a code-mode exec call is running;
2. resume from a rollout ending in custom_tool_call;
3. projection of one malformed task without terminating the shared app-server;
4. clearing frontend fatal state after intentional restart.

Related issues

• #41988 — same Windows desktop fatal UI and 0xC000013A symptom
• #41566 — separate duplicate-ordinal corruption after unfinished turns
• #30600 — missing custom tool output causing app-server failure

The duplicate-ordinal issue is related operationally but is not required for this reproduction.

Start with the desktop error page's Restart ChatGPT path and its AppServerConnection/stdio transport logs, then inspect how the canonical paginated rollout handles an in-flight custom_tool_call. Reproduce the Windows restart boundary and add regression coverage for safe interruption or recovery, task isolation, shared app-server survival, and clearing the frontend fatal state.