Windows Codex app resource exhaustion, LiveKernelEvent 0x1CC, and unexpected reboot

Windows Codex app resource exhaustion causes system-wide hang and unexpected reboot

Summary

The Windows Codex desktop environment appears to start multiple copies of the same local STDIO MCP server chains across active tasks. On 30 July 2026, this coincided with extreme process growth, approximately 96% committed-memory utilization, a Windows LiveKernelEvent 0x1CC (EXRESOURCE_TIMEOUT_LIVEDUMP), a system-wide hang, and an unexpected reboot.

This happened twice during the day from the user's perspective. One occurrence produced a complete Windows kernel/WER record.

The evidence supports a process-lifecycle/resource-exhaustion issue associated with the Codex desktop environment or its handling of globally configured MCP servers. It does not prove which Codex component is responsible, but Windows hardware, disk, display-driver, and component-store checks did not identify an alternative primary cause.

Severity and impact

• Severity: Critical
• Impact: Whole Windows session became unresponsive and rebooted unexpectedly
• Data-loss risk: Active work and unsaved application state can be lost
• Recurrence: Observed twice on the same day; one full kernel incident captured
• Current status: Locally mitigated by disabling automatic startup of selected MCP servers

Environment

• OS: Windows 10 Pro 22H2
• OS build: 19045.7548
• Codex Windows package: OpenAI.Codex 26.721.4979.0
• ChatGPT Desktop package also installed: OpenAI.ChatGPT-Desktop 1.2026.190.0
• CPU: Intel Core i5-14600KF
• RAM: 32 GB
• GPU: NVIDIA GeForce RTX 4060 Ti
• GPU driver: 32.0.15.9649
• System drive: Crucial CT1000P3PSSD8 NVMe, reported healthy
• Page file: Windows-managed, approximately 63 GB allocated

Incident timeline

All times are Europe/Istanbul (UTC+03:00) on 30 July 2026.

1. Around 00:29, Windows began recording repeated service and DCOM timeouts.
2. At approximately 00:36-00:37, Windows Error Reporting captured LiveKernelEvent 0x1CC.
3. The live dump recorded a kernel resource timeout of 150 seconds.
4. At 00:38, Winlogon recorded slow logoff processing.
5. At 00:39:35, the system shut down unexpectedly.
6. At 00:40:44, Windows recorded Kernel-Power event 41.
7. At 00:40:50, Event Log event 6008 confirmed the unexpected shutdown.

Windows crash evidence

• Event type: LiveKernelEvent
• Bugcheck/live-dump code: 0x1CC
• Microsoft name: EXRESOURCE_TIMEOUT_LIVEDUMP
• WER report ID: 58e82bc8-0b27-4b7a-806b-c805cbcfed4e
• Dump filename: ResourceTimeout-20260730-0036.dmp
• Timeout parameter: 0x96 (150 seconds)
• Unexpected shutdown: Kernel-Power 41
• BugcheckCode in event 41: 0

Microsoft documents 0x1CC as a live dump generated when a kernel ERESOURCE wait times out, potentially indicating a deadlock or severe resource contention:

https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x1cc--exresource-timeout-livedump

Process and memory evidence

The Windows Error Reporting process snapshot associated with the incident showed:

| Process group | Count | Approximate private memory |
|---|---:|---:|
| node.exe | 158 | 13.79 GiB |
| cmd.exe | 133 | Not separately aggregated |
| PowerShell processes | 22 | Not separately aggregated |
| Python processes | 15 | Not separately aggregated |
| codex.exe | 2 | 7.28 GiB |
| Main codex.exe process | 1 | 7.26 GiB |
| Chrome processes | 18 | 3.56 GiB |
| Desktop host process | 1 | 1.27 GiB |

• Total private memory in the snapshot: approximately 33.65 GiB
• Peak committed memory: approximately 93 GiB
• Commit limit: approximately 97 GiB
• Peak commit utilization: approximately 96%

Repeated process trees were associated with local MCP servers such as Playwright, Firebase, Firecrawl, Postman, Mobile MCP, Sequential Thinking, filesystem/project helpers, and XcodeBuildMCP. Timestamps and parent-child relationships were consistent with several active Codex tasks each starting a broad set of globally configured local MCP servers.

Evidence against common alternative causes

• No new application-specific WER crash was found for the OpenAI/Codex desktop process at the incident time.
• No WHEA hardware error was found.
• No NVIDIA/display-driver reset event was found.
• No storage, NVMe, disk, or filesystem error was found.
• DISM /ScanHealth: no component-store corruption.
• chkdsk C: /scan: no filesystem problems and zero bad sectors.
• sfc /scannow: repaired a minor Windows integrity issue.
• A subsequent sfc /verifyonly: no integrity violations.

The repaired SFC item was not temporally or technically consistent with the observed process explosion and is not considered the primary trigger.

Evidence-supported root-cause hypothesis

The likely trigger was multiplicative startup and retention of local MCP process trees across multiple active Codex tasks:

1. A large global MCP configuration was enabled.
2. Multiple active Codex tasks appeared to start separate copies of many local STDIO MCP servers.
3. Several MCPs used nested cmd.exe, node.exe, npx, PowerShell, or Python launcher chains.
4. Process counts and committed memory continued growing.
5. Windows reached severe memory and kernel-resource contention.
6. A 150-second kernel ERESOURCE timeout was captured, followed by a system-wide hang and unexpected reboot.

OpenAI should confirm whether the Windows app starts one MCP server set per task, whether server processes are shared or bounded, and whether abandoned/completed tasks can leave child process trees running.

Local mitigation performed

The following servers were not uninstalled. Their automatic global startup was disabled so they can be re-enabled when a project explicitly needs them:

• Playwright
• Chrome DevTools
• Firecrawl
• Postman
• Mobile MCP
• Sequential Thinking
• Firebase
• Project-specific game/filesystem helpers
• Project-specific Git MCP
• XcodeBuildMCP plugin on Windows

The exact already-running child process trees were then stopped by verified PID ancestry. No broad process-name termination was used.

This is a safe-start mitigation, not a claim that these tools are unnecessary. Playwright/Chrome DevTools, Firebase, Mobile MCP, and Postman may be needed for particular projects and should remain available for selective, on-demand activation.

Project-scoped selective reactivation

Codex session records from the preceding 60 days were inspected for actual tool calls, excluding tool names that appeared only in instructions or configuration. The following project-scoped overrides were then added:

| Project | Re-enabled MCP servers | Evidence |
|---|---|---|
| Strateji Oyunu | Playwright, Firecrawl | 67 Playwright calls and 2 Firecrawl calls |
| PDF Programı | Firecrawl | 66 calls across 7 sessions |
| Futbol Oyunlari | Firecrawl | 17 calls across 3 sessions |
| Video | Chrome DevTools, Firecrawl | 4 Chrome DevTools calls and 1 Firecrawl call |
| Repertuarhane project | Mobile MCP | 1 device-discovery call |

Postman, Sequential Thinking, game-files, and git-local had no verified calls in the review window and remain disabled.

A single Firebase developer-documentation search was observed from the unrelated PDF Programı project, while the configured Firebase MCP command targets the Uzay Kolonisi Oyunu directory. This was treated as a scope mismatch rather than valid project usage, so Firebase remains disabled until a Firebase task in the target project actually needs it.

The project overrides contain only enabled and timeout values. Commands and credentials remain in the user-level configuration and are not copied into repositories. Effective configuration was verified with codex mcp list --json: the global/default profile keeps all nine heavy servers disabled, while each listed trusted project enables only its assigned one or two servers.

Result after mitigation

| Metric | Before mitigation | After mitigation |
|---|---:|---:|
| node.exe count | 135 immediately after reboot; 158 in crash snapshot | 29 |
| cmd.exe count | 109 immediately after reboot; 133 in crash snapshot | 3 |
| Committed-memory utilization | Approximately 96% at peak | 19% |
| Available physical RAM | Approximately 8.8 GiB shortly after reboot | Approximately 20 GiB |
| New relevant critical events | N/A | None during the verification period |

The disabled process groups did not respawn during the observation period.

Suggested reproduction/diagnostic path

Because another full system hang is risky, this should be reproduced only with resource monitoring and a safe commit-memory threshold:

1. Use the Windows Codex app with a global configuration containing multiple local STDIO MCP servers.
2. Open several local Codex tasks.
3. Observe whether every task creates a complete new set of MCP launcher and runtime processes.
4. Close/archive/complete tasks and verify whether their MCP process trees terminate.
5. Monitor process count, private bytes, committed bytes, and parent PID ownership.
6. Verify whether MCP instances are shared, pooled, lazily started, or unbounded per task.

Expected behavior

• Local MCP servers should start lazily when required or have clearly bounded per-task ownership.
• Completed, cancelled, or abandoned tasks should release their child process trees.
• Multiple tasks should not silently multiply all globally configured MCP servers until the OS approaches its commit limit.
• The app should detect rapid process/commit growth and warn or stop additional server startup before system-wide instability.

Actual behavior

• Many copies of the same local MCP server chains accumulated.
• The process growth consumed most of the Windows commit limit.
• Windows captured a kernel resource timeout and then rebooted unexpectedly.

Requested investigation

Please investigate:

1. MCP server lifecycle and cleanup in the Windows Codex app.
2. Whether globally configured local MCP servers are launched once per task.
3. Whether completed or inactive tasks retain MCP child processes.
4. Whether nested npx/cmd.exe launcher chains are fully terminated.
5. Whether the app can enforce process, memory, or commit-pressure safeguards.
6. Whether Windows app telemetry can be correlated with WER report ID 58e82bc8-0b27-4b7a-806b-c805cbcfed4e.

Additional artifacts

The following local artifacts are available and can be shared after a privacy review if an OpenAI engineer requests them:

• Windows WER Report.wer
• ResourceTimeout-20260730-0036.dmp
• WER system-data XML
• WER process/memory CSV
• Sanitized Codex MCP configuration excerpt
• DISM, SFC, and CHKDSK diagnostic transcripts

Raw session transcripts and the full global configuration are intentionally not attached because they may contain project paths, prompts, or other private information.

OpenAI_Codex_Windows_Resource_Exhaustion_Report.docx

OpenAI_Codex_Windows_Resource_Exhaustion_Report.docx