`[Windows][Desktop 26.707.9981.0] Repeated ChatGPT.exe AppCrash with exception 0xc06d007f during normal Codex tool use

Suggested title

[Windows][Desktop 26.707.9981.0] Repeated ChatGPT.exe AppCrash with exception 0xc06d007f during normal Codex tool use

What version of the Codex App are you using?

Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0

ChatGPT.exe file/product version: 150.0.7871.115

What subscription do you have?

<!-- Replace this line with Plus, Pro, Business, Enterprise, etc. -->

What platform is your computer?

• Windows 11 Home China, version 25H2, build 26200.8875, x64
• Intel Core i7-12700H, 20 logical processors
• 16 GB RAM
• NVIDIA GeForce RTX 4070 Laptop GPU, driver 566.07
• Intel Iris Xe Graphics
• SMI USB Display adapter

What issue are you seeing?

The unified ChatGPT/Codex Windows desktop app repeatedly spawns short-lived ChatGPT.exe processes that crash with the same Windows Application Error while the main app process remains alive. During normal Codex tool use, the UI becomes very slow or temporarily unresponsive, tool output is delayed, and Windows continuously records new crash reports.

Windows Application log evidence:

• Provider: Application Error
• Event ID: 1000
• Faulting application: ChatGPT.exe
• Faulting package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
• Faulting module: unknown
• Exception code: 0xc06d007f
• WER event type: MoAppCrash

Observed crash frequency on July 16, 2026:

• 96 Application Error events during the day
• 39 Application Error events in one 15-minute window
• All sampled events used exception code 0xc06d007f
• The issue continued after a Windows reboot

Windows also previously recorded:

• RADAR_PRE_LEAK_64 for Codex.exe on July 6
• RADAR_PRE_LEAK_64 for ChatGPT.exe on July 10

While sampling the process tree, additional ChatGPT.exe processes appeared for a few seconds and disappeared again. This coincided with new WER crash records. The primary desktop process stayed running, so the user-visible result was repeated stalls rather than one clean application exit.

The app package status and common Windows App Runtime/VCLibs dependencies report Ok. AppModel-Runtime logs show successful package launches and no corresponding deployment failure.

What steps can reproduce the bug?

I do not yet have a minimal deterministic reproduction, but the following reproduces the failure repeatedly on this machine:

1. Reboot Windows.
2. Launch the Microsoft Store ChatGPT/Codex desktop app.
3. Open a single local Codex task. The project used for diagnosis is empty and is not a Git repository.
4. Run ordinary read-only tool calls such as system/process inspection and MCP-backed operations.
5. Continue using the task for several minutes.
6. Observe the UI becoming slow or temporarily unresponsive.
7. Open Windows Event Viewer -> Windows Logs -> Application.
8. New Application Error Event ID 1000 entries for ChatGPT.exe appear repeatedly with exception 0xc06d007f.

What is the expected behavior?

• Normal Codex tool use should not spawn repeatedly crashing ChatGPT.exe processes.
• The desktop UI should remain responsive while tools run.
• Completed or failed tool runtimes should be reclaimed.
• Windows Event Viewer should not receive continuous MoAppCrash reports.

What is the actual behavior?

• The desktop UI intermittently freezes or becomes very slow.
• Short-lived ChatGPT.exe processes appear and disappear.
• Windows logs repeated MoAppCrash / Event ID 1000 entries.
• The main app survives, making the failure look like repeated stalls rather than a full app exit.

Additional diagnostic information

At one process-tree snapshot, the ChatGPT/Codex tree contained:

• 51 processes
• approximately 3.06 GB working set
• approximately 2.89 GB private memory
• 14,732 handles
• 1,228 threads

The configuration contained one node_repl MCP server, but 18 instances of node.exe ./mcp/server.mjs and 18 matching runtime processes were alive. They were stable during a 30-second sample but consumed approximately 1.1 GB private memory and about 6,700 handles in aggregate. I am not claiming this is the same root cause as the crash; it may be a separate lifecycle issue.

Local diagnostic SQLite state:

• %USERPROFILE%\.codex\logs_2.sqlite: 317.42 MB
• logs_2.sqlite-wal: 4.24 MB
• approximately 159,570 log rows
• 72,064 TRACE rows
• 42,688 DEBUG rows
• no measurable database/WAL size growth during a 20-second idle sample

The largest log targets were codex_core::stream_events_utils, codex_api::sse::responses, and codex_mcp::connection_manager. I am including these as secondary observations, not as proof of the crash root cause.

Checks that did not identify another primary cause:

• Current project: empty, no Git repository, no node_modules, .venv, build, or generated directories
• WSL distributions: all stopped
• Active agents in the affected task: one
• System drive: more than 100 GB free; disk queue was low
• WinHTTP: direct connection
• User proxy: disabled
• VPN/TUN adapter: disconnected
• TCP 443, HTTPS, TLS 1.3, and an OpenAI WebSocket handshake succeeded
• No evidence of TLS interception
• Windows Defender and firewall remained enabled

Mitigations tried

• Rebooted Windows; the crash loop returned after launching the app
• Reduced the test to one task and one agent
• Used an empty project to exclude indexing/file-watcher load
• Confirmed that the failure is not accompanied by WSL, VPN, proxy, or large-repository activity

I have not modified logs_2.sqlite, disabled security software, reset the app, or reinstalled it.

Related issues

• Windows AppHang and RADAR_PRE_LEAK_64, but with a different proxy-related setup: https://github.com/openai/codex/issues/19685
• MCP helper process accumulation on macOS/subagents: https://github.com/openai/codex/issues/17574
• Excessive TRACE writes to logs_2.sqlite-wal: https://github.com/openai/codex/issues/17320

Logs and privacy

I can provide the following if a maintainer requests them:

• redacted Event ID 1000/1001 entries
• redacted Report.wer metadata
• a sanitized process-tree snapshot
• an in-app feedback/session ID

I have not attached the full SQLite database, session transcripts, WER dump files, authentication data, usernames, project paths, or remote host names because they may contain sensitive information.