›_ Codex Issues
Codex Issues / #34305

Windows Desktop 26.715.4045 repeatedly becomes unresponsive (MoAppHang) after memory spikes

Open 💬 3 comments Opened Jul 20, 2026 by tanwenjinsix
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

  • Microsoft Store package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
  • Desktop executable: ChatGPT.exe
  • Chromium/file version reported by WER: 150.0.7871.124
  • Desktop client version seen in app-server logs: 26.715.31925
  • Bundled/active app-server client version observed: 0.144.6

What platform is your computer?

  • Windows x64
  • Windows Error Reporting dynamic OS build: 10.0.26200.2
  • WER base OS version: 10.0.26100.8894
  • 64 GB RAM

What issue are you seeing?

Codex Desktop consistently becomes unresponsive after launch and is then closed by Windows. This reproduces after a clean app reinstall and after deleting %USERPROFILE%\.codex.

Windows records the same fatal hang on every reproduction:

Provider: Application Hang
Event ID: 1002
Program: ChatGPT.exe
Version: 150.0.7871.124

Event Name: MoAppHang
P1: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
P2: praid:App
P3: 150.0.7871.124
P4: 6a555ada
P5: 0000
P6: 134217728
Fault bucket: 1777514585603502314
Hashed bucket: d43997ef4a3ceec0b8ab001911f8f0ea

Windows also recorded RADAR_PRE_LEAK_64 for ChatGPT.exe.

During monitoring, the combined private memory of the Electron/Chromium process group sometimes increased from approximately 868 MB to 2.56 GB in about five seconds. It could later fall back, but the UI eventually entered the fatal MoAppHang state.

Steps to reproduce

  1. Install/open Codex Desktop from the Microsoft Store.
  2. Sign in and leave the main window open.
  3. Use the app normally or simply wait.
  4. After a short period, the UI becomes sluggish and then completely unresponsive.
  5. Windows closes the application and records Event ID 1002 plus WER MoAppHang.

Troubleshooting already performed

The identical hang still occurred after each of these isolation tests:

  • Uninstalled and reinstalled Codex Desktop.
  • Deleted and regenerated %USERPROFILE%\.codex.
  • Switched the selected host from remote control to local.
  • Disabled GPU acceleration using --disable-gpu --disable-gpu-compositing.
  • Disabled all 10 configured plugins.
  • Disabled the node_repl MCP server.
  • Tested Clash/Mihomo with TUN enabled.
  • Tested with TUN disabled and Windows system proxy enabled.
  • Verified there were no GPU driver reset events near the hangs.
  • Session history was tiny (approximately 0.21 MB), so this was not an image-heavy or long-history thread.

The same WER fault bucket was produced in all configurations.

Additional log observations

The local app-server log contained compatibility-looking warnings/errors:

failed to load models cache: missing field supports_reasoning_summaries
ignoring invalid experimental feature enablement keys: apps_mcp_path_override
failed to load plugin: missing or invalid plugin.json plugin="sites@openai-bundled"

There appears to be a version difference between the Store package (26.715.4045.0) and the desktop client version reported to app-server (26.715.31925). It is not yet proven whether this mismatch is causal.

Expected behavior

Codex Desktop should remain responsive and should not be terminated by Windows during startup or normal idle/use. If a network request, plugin, cache migration, or app-server operation fails, it should time out or show a recoverable error instead of blocking the Electron UI process.

Privacy note

Raw .codex logs and WER files are not attached because they can contain local paths, prompts, and account/session identifiers. Sanitized excerpts or additional diagnostics can be provided if maintainers request them.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34117
  • #34244

Powered by Codex Action

carryon-11 · 1 month ago

I can reproduce what appears to be the same underlying hang, with the identical WER bucket/hash:

  • EventType: MoAppHang
  • ConsentKey: AppHangXProcB1
  • Hang Type: 134217728
  • Hashed bucket: d43997ef4a3ceec0b8ab001911f8f0ea
  • Chromium/file version in the latest WER event: 150.0.7871.124
  • Latest affected Store package recorded by WER: OpenAI.Codex_26.715.4045.0
  • Windows build: 26200.8875
  • 32 GB RAM

A strong and repeatable trigger in this environment is window occlusion/backgrounding:

  1. Start a local Codex task that runs for at least a minute.
  2. Keep the Codex window visible: the task and UI continue normally.
  3. Minimize Codex to the taskbar, or completely cover it with another application.
  4. Return to Codex after a short period.
  5. The entire UI is frozen and no longer interacts with Windows.

Task Manager or terminal force-termination can leave the frozen window visible, and a full Windows reboot has been required to recover.

Important contrast with memory pressure: approximately 18 GB of RAM was still available during diagnosis. ChatGPT Classic was not running. The renderer logs repeatedly showed ResizeObserver loop completed with undelivered notifications while rendererWindowFocused=false, and the Codex GPU process was active.

The first failure appeared around July 16, 2026, immediately after a sequence of Store updates began. Windows recorded failures across these packages:

  • 26.707.9981.0 (crash)
  • 26.715.2305.0 (hang)
  • 26.715.3651.0 (hang)
  • 26.715.4045.0 (hang)

The currently installed package after reboot is 26.715.7063.0; reproduction on that build has not yet been confirmed.

Because the WER bucket is identical but the reliable trigger is minimizing or fully occluding the window, this may help narrow the problem to Windows background/occlusion handling, renderer throttling, or the GPU process rather than system memory exhaustion alone. No raw logs or local paths are included here.

Mavumavu · 1 month ago

Current-build recurrence with the same WER signature component, after the earlier 26.715 HID discovery rework:

  • Package: OpenAI.Codex_26.715.10079.0_x64
  • ChatGPT.exe: 150.0.7871.124
  • Windows Application Hang/WER at 2026-07-22 18:29:50–18:29:52 +02:00
  • Event: MoAppHang
  • Signature: P4=6a555ada, P5=0000, P6=67246080
  • Fault bucket: 1745795687641397029; hashed bucket: a1785b263a08a89db83a4feda4463725
  • AppModel-Runtime destroyed the Codex AppX container at the hang timestamp.
  • Windows then initiated a full shutdown at 18:30:17 and booted at 18:30:36; the new Codex AppX container was created at 18:31:08. The MoAppHang therefore preceded shutdown by roughly 27 seconds, while the reboot remains part of the recovery sequence.

This matches this issue's P4=6a555ada but has a different P6/bucket and reproduces on the newer package. A configured 5-minute task heartbeat produced no continuation before the failure and has now been paused because it shares the app-host lifecycle. No git, gh, npm, or npx process was active at recovery. The full sanitized host-lifecycle timeline is also recorded at https://github.com/openai/codex/issues/17229#issuecomment-5048797578.

The current main process loads hid-topology-watcher.node, not the older HID.node module, so this comment does not claim the old synchronous nodeHID.devices() root cause. A Razer gaming HID is connected, but a native hung-thread stack or controlled unplug A/B is still needed before attributing this recurrence to HID.