›_ Codex Issues
Codex Issues / #34907

[Windows Desktop regression][26.715.10079.0] Project/tool calls trigger 92-100% CPU, UI freeze, and KERNELBASE crashes

Open 💬 4 comments Opened Jul 23, 2026 by wendylu2024
💡 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?

OpenAI.Codex 26.715.10079.0 from the Microsoft Store.

Additional version details observed locally:

  • Desktop executable: ChatGPT.exe 150.0.7871.124
  • Bundled Codex runtime: 0.145.0-alpha.30
  • App-server startup logs report client version 26.715.72359

Windows deployment history shows that 26.715.8383.0 was installed on July 21 and was replaced by 26.715.10079.0 on July 22. The user reports that the older build was stable and that the repeated freezes/crashes began after this update.

What subscription do you have?

Not provided.

What platform is your computer?

  • Windows x64, OS build 26200.8875
  • Intel Core Ultra 5 225H, 14 logical processors
  • 32 GB RAM
  • Intel Arc 130T GPU
  • Native Windows workspace (not WSL)

What issue are you seeing?

Summary

After the Desktop app updated to 26.715.10079.0, starting or resuming a project conversation and allowing Codex to run ordinary read-only project inspection commands can make the Desktop UI unresponsive while total CPU jumps to approximately 92–100%.

This is not limited to opening multiple windows. A simple text-only conversation may initially remain responsive, while a second/new project conversation freezes around its first shell/tool call. The same failure can later occur in the original single window, especially after project or diagnostic commands produce more output.

After restarting the app, the affected turn is normally marked interrupted: the assistant's commentary remains visible, but the shell result was never persisted.

Windows Error Reporting confirms actual application failures, not only perceived UI lag:

  • 2026-07-23 13:40:58 — ChatGPT.exe 150.0.7871.124, faulting module KERNELBASE.dll, exception 0xe0000008, offset 0x00000000000c1ada
  • 2026-07-23 15:27:54 — the same executable, module, exception, and offset
  • During the preceding night, Windows also recorded seven codex.exe Application Error events, six sharing exception 0xc0000409 at offset 0x000000000d2cbf31
  • One codex-code-mode-host.exe failure was recorded with exception 0x80000003

Sanitized local diagnostics

The local SQLite feedback log is not continuously writing while idle, but it shows a large active-use burst:

  • 8-second idle sample: 0 new rows and 0 KB database/WAL growth
  • 10-minute active sample: 2,205 rows, including 1,925 TRACE rows
  • Estimated retained log content during that sample: approximately 2.94 MB
  • Peak insertion rate: 206 rows/second
  • 939 TRACE rows contained unhandled responses event
  • Largest targets by row count:
  • codex_api::sse::responses: 1,185
  • codex_app_server::outgoing_message: 636
  • codex_core::stream_events_utils: 79
  • Current files at the time of inspection:
  • logs_2.sqlite: approximately 13.04 MB
  • logs_2.sqlite-wal: approximately 4.21 MB

This is a correlation, not proof that SQLite logging is the sole cause. It may amplify a renderer/app-server or tool-call failure during active turns.

There were also 1,146 WMI Activity Event ID 5858 failures in a six-hour diagnostic window. Most came from repeated network-adapter statistics queries by historical client PIDs that had already exited, so attribution to Codex is not proven. This may be adjacent to #34014, but the primary evidence in this report is the reproducible project/tool-call trigger and the matching Windows crash signatures.

Plugin churn does not currently appear to be the dominant trigger. After setting plugins=false and remote_plugin=false, only 13 plugin/list matches appeared in the same recent 10-minute window, but the freezes continued.

What steps can reproduce the bug?

The failure is intermittent but has occurred repeatedly with this sequence:

  1. Launch Codex Desktop on Windows.
  2. Open a local Git project or create a new conversation associated with that project.
  3. Ask Codex to perform a read-only inspection, for example:
  • read a small set of handoff/documentation files;
  • run git status or inspect a short Git log;
  • summarize the project without modifying it.
  1. The assistant posts its initial commentary and begins a shell/tool call.
  2. The Desktop UI becomes unresponsive and total CPU rises to approximately 92–100%.
  3. Force-close or restart Codex.
  4. Reopen the conversation. The turn is shown as interrupted and no tool result was saved.

A tightly constrained background inspection sometimes completes, which suggests the regression may be burst/size/timing-sensitive rather than affecting every tool call.

What is the expected behavior?

Ordinary project inspection and shell tool calls should complete without pegging the CPU, freezing the renderer, or crashing ChatGPT.exe/codex.exe. A new project conversation should remain usable on a 14-logical-CPU, 32 GB machine.

Troubleshooting already attempted

  • Clean uninstall and reinstall from the Microsoft Store
  • Moved CODEX_HOME from the system drive to a drive with more free space
  • Disabled GPU acceleration; the issue persisted
  • Disabled plugins and remote plugins; the issue persisted
  • Used only one Codex window; the issue still occurred
  • Restarted Windows and Codex repeatedly
  • Attempted to force HTTP/SSE for a proxy environment; Desktop startup still selected the built-in OpenAI transport/WebSocket capability

The problem began before the transport/config experiments.

Privacy / attachments

Raw logs_2.sqlite, session JSONL, and application logs are intentionally not attached because they can contain prompts, local paths, tool output, and private project content. Sanitized aggregate diagnostics can be provided if maintainers request them.

CPU screenshots are available, showing approximately 92% and 100% total CPU during two freezes, but they contain no useful per-process breakdown and are therefore not attached here.

Possibly related issues

  • #34014 — Windows standalone app / WMI Provider Host at 90–100% CPU
  • #34577 — Windows high-CPU PowerShell processes after shell tool calls
  • #21134 — Desktop app-server/renderer slowdown with TRACE log churn
  • #24275 and #31111 — high-volume logs_2.sqlite / TRACE logging during active use

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33822

Powered by Codex Action

Baz-Len · 29 days ago

Adding a sanitized Windows Desktop datapoint that appears related, but with a different resource profile than the original report.

Environment

  • Platform: Windows laptop
  • RAM: 16 GB
  • Active Desktop process path indicates package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Get-AppxPackage did not expose a package row locally, so the process path is the clearest version signal.
  • Affected surface: Codex / ChatGPT Desktop app on Windows.
  • Browser input was normal during the same episode: Gmail and Google search typed/submitted without lag.

Summary

The Desktop app can become severely laggy or partially stale at the UI layer. The backend appears to receive and process messages before the local Desktop UI acknowledges or renders them.

During the worst episode, a full follow-up message could be typed before the previous message visibly registered in the Desktop app. In some cases, the submitted user message and assistant response appeared in the Desktop UI at the same time, suggesting the backend had already processed the message while the local UI was behind.

Observed symptoms

  • Typing in the Codex composer lagged badly.
  • The send spinner sometimes took roughly 10+ seconds.
  • At times the send/backend path appeared immediate, but chat display/render and typing echo still lagged.
  • Returning/focusing Codex Desktop from the browser took roughly 20 seconds.
  • Task/thread switching can take more than 5 seconds before the selected task displays.
  • Codex launch has caused slow startup and jumpy mouse behavior for roughly 10+ seconds for about two months, but this episode was materially worse.
  • The issue reproduced even with only one Codex task actively working.
  • A prior remote episode involved multiple long-running tasks where a third task would not start, the first two appeared to spin, remote showed reconnect-to-laptop/task problems, and later the long-running tasks had completed. That suggests task execution survived while the Desktop/remote attachment/status path went stale.

What was ruled down locally

  • Not general Windows typing lag: Gmail and Google search input were normal during the same episode.
  • Not obvious browser/network lag: Google search began immediately after pressing Enter.
  • Not phone USB-C: unplugging the phone charging cable did not improve the lag.
  • Not USB mouse receiver: unplugging the mouse receiver and using the trackpad did not improve the lag.
  • Not simple resource saturation during sampled periods:
  • available RAM stayed around 5.5-5.9 GB
  • disk activity stayed low with queue around 0.01-0.02
  • processor queue stayed 0
  • sampled ChatGPT and codex process CPU deltas were around 0.2%
  • No visible live git or taskkill process storm was present during local cross-check, so this does not appear to be the same local variant as taskkill/conhost storm reports.

Restart behavior

  • Codex-only restart did not fully clear the issue.
  • Full Windows restart improved the issue but did not fully resolve it.
  • After restart, one message had no lag, suggesting temporary recovery is possible, but the underlying issue appears to persist in the current build.

Expected behavior

  • Composer typing should echo immediately.
  • Sending should visibly register promptly.
  • The local Desktop UI should render the submitted user message before, or at least as soon as, backend processing begins.
  • Switching/focusing the Codex Desktop window should not take 5-20 seconds when the rest of Windows/browser input is responsive.

Request

Please investigate the Windows Desktop UI/composer/render/window-activation path for cases where backend message receipt continues but the local Desktop UI acknowledgement/rendering falls behind. This may be related to recent Windows Desktop package updates and task/thread hydration or renderer state handling.

lips0127 · 18 days ago

Current-build reproduction on Codex Desktop for Windows:

  • Codex Desktop package: 26.803.5235.0
  • Windows 25H2, x64
  • Cold restart: system CPU averaged 77.2% in the first 30 seconds and peaked at 96.1%.
  • A six-minute process-lifecycle sample recorded 131 git.exe starts, 214 conhost.exe starts, and 13 PowerShell starts.
  • All 131 Git processes exited in this sample. This looks like repeated repository refresh/cancellation/retry activity rather than only an orphan-process leak.
  • The main desktop process and app-server each reached roughly 45% of total-machine CPU.
  • Memory was not the primary limiter.

I ran two controlled exclusions:

  1. Switched to a branch whose local/remote comparison was zero.
  2. Stopped new TRACE/DEBUG database writes and confirmed that the log database timestamp remained unchanged during the next sample.

The Git/console loop persisted: a later 90-second active sample still recorded 50 Git starts and 67 conhost starts, with the app-server peaking above 41% total-machine CPU. Large diffs and high-frequency logging can amplify the problem, but neither is a sufficient root cause in this reproduction.

The workspace has a valid independent Git root, and a dry-run worktree prune found no stale worktrees. The app repeatedly invoked repository status/config/remote checks, including status calls that explicitly request ignored/untracked paths.

Possible fixes worth investigating:

  • debounce/coalesce repository refreshes across UI consumers;
  • add backoff after cancelled or overlapping Git queries;
  • cache branch-diff and remote metadata while the repository state is unchanged;
  • avoid ignored/untracked enumeration unless the Changes UI explicitly needs it;
  • provide a per-project switch for automatic Git integration;
  • expose privacy-safe refresh counters so users can distinguish Git refresh, indexing, and logging load.

This appears related to #17229 and #20567, but the current trace shows high-frequency short-lived Git/conhost churn even when no orphan Git process remains.

c78815999-cmd · 14 days ago

I’m seeing a very similar severe regression on Windows after the recent Codex/ChatGPT desktop update.

Observed in Task Manager while using a local project:

  • ChatGPT/Codex process group memory increased from ~4.5 GB to ~6.4 GB
  • CPU around 27–28% for the app process group
  • Disk throughput spiked from ~36.8 MB/s to ~234.9 MB/s
  • Total system memory reached ~84% on a 16 GB machine
  • The entire desktop became sluggish, including visible mouse/cursor stutter, and even taking screenshots became difficult
  • WMI Provider Host was at 0% CPU in the sample, so W