Codex Desktop on Windows - app-server exits with 0xC000013A, leaving a missing tool output and a blank conversation panel

Subject: Codex Desktop on Windows - app-server exits with 0xC000013A, leaving a missing tool output and a blank conversation pane

Hello,

I am experiencing a recurring Codex Desktop failure on Windows. It affects both a long-running conversation and a completely new conversation, so it does not appear to be caused by accumulated chat history.

Environment:

• OS: Windows 11 x64, build 26200
• Installed MSIX package: OpenAI.Codex 26.911.7940.0
• Desktop frontend release reported in logs: 26.911.61220
• Bundled app-server CLI: codex-cli 0.155.0-alpha.2.6
• Native Windows / PowerShell environment
• Local development task with Full Access

Observed behaviour:

1. I submit a development task.
2. Codex starts normally and executes several commands.
3. During a tool call, the entire conversation content disappears and the pane becomes blank.
4. The main desktop application remains running.
5. The app-server is restarted automatically.
6. Retrying may display:
   "Error submitting message"
   "timeout"
7. The same problem reproduced in a newly created conversation.

The failing conversation ID was:
01a0b3b6-768b-7453-9d55-603d126d9d7c

The interrupted tool call ID was:
call_keTgUtG4r2zDB1rQxCHoe5NX

Important timeline, UTC:

• 2026-09-18 09:12:39: the custom exec tool call was persisted.
• 2026-09-18 09:12:47.267:
  app_server_connection.closed code=3221225786
• 2026-09-18 09:12:47.273:
  Codex CLI process exited
  classifiedAsExpected=false
  code=3221225786
• 2026-09-18 09:12:47.273:
  fatal_error_broadcasted
• 2026-09-18 09:12:49.960:
  app_server_restart_recovery_done
  resumedCurrentConversation=true

3221225786 is 0xC000013A / STATUS_CONTROL_C_EXIT.

After recovery, the session contained the custom tool call but no corresponding tool output. The backend then reported:

Custom tool call output is missing for call id:
call_keTgUtG4r2zDB1rQxCHoe5NX

The interrupted command was not a background process. It was a normal foreground exec that checked a Windows Scheduled Task, enumerated collector processes, and ran one Python unit test.

Additional observations:

• The main ChatGPT.exe process survived.
• A replacement codex.exe app-server was started automatically.
• No matching Windows Application Error or Windows Error Reporting event was recorded.
• No Crashpad dump was created for this incident.
• The context limit was not reached:
  full_context_window_limit_reached=false
• A separate legacy_notify warning occurred earlier:
  "The filename or extension is too long. (os error 206)"
  The log says "after_agent hook failed; continuing", so I cannot establish that this warning caused the later app-server termination.

This appears to match:
https://github.com/openai/codex/issues/45219
and possibly:
https://github.com/openai/codex/issues/41988

Expected behaviour:

• A tool interruption or app-server restart should not leave an unmatched tool call in the persisted conversation.
• The conversation pane should remain visible.
• Recovery should either restore the tool call or mark it as failed and allow the task to continue.
• A child app-server failure should not result in a blank conversation pane or repeated message-submission timeouts.

Could you please confirm whether this is the same known Windows app-server lifecycle issue and whether a fixed build or temporary workaround is available?

I can provide the redacted desktop log, session JSONL, screenshots, exact timestamps, and local telemetry if required.

Start by comparing the failure with issues #45219 and #41988, then review the app-server connection-closed, restart-recovery, and fatal-error log events around the supplied call ID. Inspect the persisted session JSONL to understand how an interrupted tool call is represented; done means recovery avoids unmatched tool outputs, blank conversation panes, and repeated submission timeouts.