Codex App repeatedly crashes on Windows with error code 3221225786

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

• #32653
• #32013
• #32352

Powered by Codex Action

The issue is still reproducible on July 15, 2026.

Codex worked for approximately one minute and then crashed again with error code 3221225786.

The crash dialog displayed:

Failed to create shell snapshot for powershell:
Shell snapshot not supported yet for PowerShell

Before the crash, Codex also reported that reading Windows process command lines was denied by permissions, but it successfully continued by checking PID/runtime files and ports instead.

I have not changed Windows security settings. Please note that the “most recent error” may be an incidental WARN rather than the actual crash cause, as reported in other Codex Windows issues.

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/c009b309-010b-4445-b63a-3b55b57be0d2" />

Codex also detected a Windows/Python environment issue in the affected project:

“The Windows venv redirector has a corrupted stored Unicode path, and the sandbox also refuses the direct system Python.”

The project is located in a Windows user directory containing OneDrive and Unicode characters. Codex attempted to bypass the virtual environment and run the base Python interpreter outside the sandbox, but the application later crashed again with code 3221225786.

I am not attaching screenshots because they contain private project information.

Forensic data point: crash storm started exactly at the silent 0.144.2 → 0.144.5 auto-update boundary (same machine, same workload — 12 abrupt terminations in one day)

Environment: Windows 11 Home 10.0.26200, ChatGPT Desktop (MSIX) 1.2026.190.0, embedded codex-cli 0.144.5 (%LOCALAPPDATA%\OpenAI\Codex\bin\494ae9d46ab9b3eb\codex.exe, installed 2026-07-16 13:00–13:05 local time, UTC+2). Same dialog as OP: exit code 3221225786 (0xC000013A = STATUS_CONTROL_C_EXIT).

What the engine's own log DB shows (%USERPROFILE%\.codex\logs_2.sqlite, table logs, grouped by process_uuid; all times local UTC+2, date 2026-07-16):

• On 0.144.2, overnight 00:45–04:30, heavy agentic workload: zero abrupt terminations.
• The app silently self-updated the engine to 0.144.5 at 13:00:00–13:04:50 (engine not running 04:30→13:00).
• First abrupt death 13:08:53 — about 4 minutes after the update. Then 11 more the same day: 14:07:42, 14:24:29, 14:44:15, 14:44:28, 14:53:04, 14:53:12, 16:09:18, 16:27:26, 18:40:46, 22:39:40, 22:42:51 (19 engine incarnations total that day; 3 clean exits, 3 ambiguous).
• Every abrupt death ends mid-flight in TRACE chatter — typically while streaming commandExecution output (codex_app_server::outgoing_message ... item/commandExecution/outputDelta, or hyper connection-pool lines) with zero shutdown lines. Three were instant re-deaths <6 s after relaunch, i.e. a crash loop (14:44, 14:53, 22:42).
• Crashpad reports/ is empty and Sentry session.json shows errors: 0 — the Electron parent never records any crash. That is consistent with the child's console being closed / receiving a console CTRL event, not with an access violation.
• Red-herring note for other readers: the WARN stream disconnected - retrying sampling request that the crash dialog happens to surface sat in a process that then survived another 4.5 minutes — it is unrelated to the terminations.
• We disabled MCP-server autoload as a test (all but one server). Deaths continued (18:40:46, 22:39:40 and 22:42:51 all happened after that change), so MCP servers appear exonerated.
• 2026-07-17: at least 2 further engine deaths on 0.144.5 on the same machine.

Hypothesis (explicitly unproven): a 0.144.5 regression in command-execution / console child-process handling on Windows — all 12 deaths occurred during active command execution, and 0.144.2 on the identical setup and workload the night before showed none. Possibly related: #16271.

Happy to provide sanitized log excerpts around any of the timestamps above.

<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/7938ad10-b072-4bf0-9e3d-434342847606" />

The issue is still reproducible after the latest update on July 19, 2026.

Codex stopped unexpectedly again while actively executing a PowerShell command. After clicking Restart, the application only reopened the existing thread. The interrupted command is marked as “Stopped” and was not resumed.

The task had completed 17 tests before the crash, but the remaining test run and the overall task were not completed.

Please confirm whether this Windows command-execution crash is being actively investigated and whether a patched build or supported rollback is available.

Current version: 26.709.11516

The failed to read canonical session metadata / rollout JSONL is empty / state-DB warnings make this a useful persisted-state diagnostic case for codex-rescue==0.1.0a4.

If you still have one affected local rollout/state set, could you start with a read-only pass:

pipx install codex-rescue==0.1.0a4
codex-rescue sessions
codex-rescue doctor --latest

It won’t repair the Desktop/VS Code crash itself, but it can distinguish empty/malformed/missing persisted session state from a runtime-only crash path.

A sanitized findings/status/count summary is enough. Please don’t post raw JSONL, databases, prompts, tool output, credentials, repository data, session IDs, or private paths.

Still seeing code=3221225786 (0xC000013A) on Store 26.820.7780.0 with [features] unified_exec = false already pinned.

The user-visible follow-on is the persisted unpaired custom-tool-call resume abort (Custom tool call output is missing …), which then kills the shared app-server. Sanitized 2026-08-27 timeline is on #32653 and #40231. Not opening a duplicate.