Windows desktop app repeatedly freezes after startup; main process memory spikes and Git subprocess calls stall

Resolved 💬 2 comments Opened Jul 19, 2026 by yuokcas-pixel Closed Jul 19, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.4045.0 (Microsoft Store package OpenAI.Codex_26.715.4045.0_x64)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro, build 26200.8875, Japanese locale; 32 GB RAM)

What issue are you seeing?

Codex for Windows repeatedly becomes unresponsive shortly after startup. The initial setup view may remain responsive, but after the normal projects/thread view loads, the main window freezes. It may recover briefly and then freeze again.

Observed diagnostics:

  • Freeze duration is typically about 35–70 seconds, followed by roughly 10 seconds of responsiveness before another freeze.
  • The main ChatGPT.exe process reports Responding=False.
  • Main-process private memory rises from approximately 320 MB to 1.3–1.5 GB during a freeze. Renderer/GPU child processes remain responsive.
  • Windows Error Reporting records repeated MoAppHang events: bucket d43997ef4a3ceec0b8ab001911f8f0ea, hang type 134217728.
  • App-server responses such as plugin/list, app/list, and account/read are sometimes delayed by approximately 30–71 seconds.
  • Background Git probes launched by the app (for example, git rev-parse --show-toplevel and git rev-parse --git-common-dir) time out at exactly 60 seconds across multiple local drives. The identical commands finish in 0.4–0.7 seconds in a normal PowerShell session.
  • The VS Code Codex extension remains responsive on the same machine.

No PII, local usernames, project names, or full local paths are included here.

What steps can reproduce the bug?

  1. Launch the Codex Windows desktop app.
  2. Complete or pass the initial setup view.
  3. Wait for the normal projects/thread view to load.
  4. Within approximately 10–35 seconds, the main window stops responding.
  5. Wait approximately 35–70 seconds; the window may recover for around 10 seconds.
  6. The freeze then repeats.

Troubleshooting already performed, with no improvement:

  • Reset persisted app UI/global state.
  • Archived all 195 threads to test with an empty project list, then restored them.
  • Tested a minimal config with no plugins or MCP servers, then restored the original config.
  • Disabled the bundled Chrome plugin, then restored it.
  • Compacted a 620 MB logs SQLite database to about 68 MB; integrity check passed.
  • Disabled Chromium GPU hardware acceleration, then restored it.
  • Disconnected USB audio/HID devices and an Xbox controller.
  • Temporarily disabled Microsoft Defender real-time protection.
  • Uninstalled recent Windows cumulative/.NET updates and rebooted.
  • Performed a complete Reset-AppxPackage after backing up package data.

The behavior reproduces after the complete app reset.

What is the expected behavior?

The desktop app should remain responsive after startup, and background project/plugin discovery or Git probes should not block the main process.

Additional information

Related component versions observed:

  • Chromium/Electron runtime reported by WER: 150.0.7871.124
  • app-server log version: 0.145.0-alpha.18

The Microsoft Defender “sample submission” prompt for .codex/config.toml appeared during diagnosis, but no threat was detected, and disabling real-time protection did not change the freezes.

I can provide sanitized logs or Windows hang dumps if maintainers specify what is needed.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗