›_ Codex Issues
Codex Issues / #37402

[Windows Desktop 26.803] MCP fleet kill/respawn cycles (taskkill /T /F storms + per-spawn network re-fetch of git-pinned MCP servers) drive kernel/Defender CPU spikes and system-wide input stutter

Open 💬 4 comments Opened Aug 7, 2026 by hiiqbiz-wq
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • App: ChatGPT/Codex Desktop 26.803.5235.0 (Microsoft Store MSIX OpenAI.Codex_26.803.5235.0_x64)
  • OS: Windows 11 build 26200
  • Hardware: Ryzen 9 9900X (12C/24T), 32 GB RAM, RTX 5070 (driver 610.47), single 3440×1440 @ 240 Hz display
  • Defender real-time protection on (default), no exclusions
  • User-configured MCP servers in ~/.codex/config.toml: one git-pinned uvx --from git+https://…@<tag> entry (serena), one local proxy exe, plus the bundled node_repl and plugin node servers

Symptom

Whenever the desktop app is open, the whole system stutters: the mouse pointer hitches across the screen and typing lags in unrelated applications. Worst at app startup; quiet when the app idles; returns on any interaction (clicking panels, switching projects, starting threads). Same class as #29949, #28855, #33776, #33786, #33711 and the Aug 6 community-forum thread "Codex Desktop on Windows 11 causes intermittent system-wide mouse stutter".

This report adds process-level measurements of one specific mechanism: the app-server tears down and re-spawns its entire MCP server fleet on thread lifecycle events, with per-PID taskkill /T /F and full re-resolution of git-pinned servers over the network each wave.

Measurements (all on an otherwise-idle machine)

1. Interaction bursts. A 500 ms-resolution CPU sampler ran while a scripted session clicked through sidebar panels (Pull requests → Sites → Plugins → New chat) and typed into the composer — no message ever sent, no agent run started:

  • App tree CPU: ~100 ms per 10 s while idle → 9,203 ms per 10 s during light clicking
  • Single 500 ms ticks: ChatGPT.exe (main) 1,469 ms CPU, codex.exe (app-server) 1,781 ms CPU
  • Two complete MCP fleet spawn waves in ~2.5 min of clicking. Each wave for the git-pinned entry: uvx → uv → git-remote-https (network fetch) → tar unpack (~8 CPU-s) → python ×2, plus node servers and the proxy exe

2. Kill/respawn cycling, caught live twice.

  • codex.exe executed taskkill /PID <pid> /T /F five times in 5 seconds, force-reaping its own uvx/node_repl/proxy/node subtrees (all victims confirmed its own children)
  • On a fresh app launch, codex.exe was again observed running taskkill /PID <node_repl-pid> /T /F on its own bundled node_repl within ~2 minutes, before any user prompt
  • Tree size cycled 23 → 48 → 39 processes within 20 minutes of light use (at peak: 4× serena stacks incl. 8 pythons, 4× proxy, 4× uvx, 4× node_repl)

3. Transmission path to system-wide input stutter. During a 120 s window with the app open: 214 process creations (~1.8/s). The kernel (System) spiked to 67% of a core and Defender (MsMpEng) to 75%, second-for-second aligned with the spawn bursts. An unboosted 5 ms sleep-loop probe measured scheduler stalls of 25–32 ms landing on exactly those seconds (p99 25.6 ms; baseline p50 overshoot 10.6 ms). With a ~125 Hz BLE mouse, those stalls are directly visible as pointer hitching. The app also holds the global timer resolution at 1 ms while open.

4. What it is NOT (ruled out by measurement). No handle/thread/memory leak slope in-window; GPU <1% and VRAM 2.4/12.2 GB; no dwm/explorer hangs or crashes in 14 days of event logs; third-party amplifiers (FxSound etc.) removed with no change. The stutter is pure scheduler perturbation from process-churn, which is why it leaves no crash fingerprints and stops the instant the app fully exits.

5. Related observations.

  • logs_2.sqlite shows the Received … for unknown conversation error flood still occurring on current builds: 6,519 errors (~35/min) across one 3-hour session and 2,739 (~46/min) in another, both on 26.7xx a few days before this test
  • Windows RADAR (RADAR_PRE_LEAK_64) flagged ChatGPT.exe as a resource-leak suspect 4 minutes into a session on an earlier build
  • One-off but suggestive: the only NVIDIA driver fatal in a month of logs (FECS UCODE exception + 160-event TDR reset storm) occurred while the app sat open idle overnight

6. Config not preserved across auto-update (secondary issue). After the silent Store update to 26.803 (installed minutes before this test), an MCP server the user had set enabled = false in ~/.codex/config.toml was found running again with enabled = true, and a previously-present project-level .codex/ config directory was gone (the global config still carries 14 dangling [hooks.state] references to its hooks.json). Attribution to the updater is circumstantial (no intermediate backup), but user MCP enablement should survive updates — each silent update currently risks re-arming exactly the fleet behavior described above.

Impact

On a 12-core workstation the app is CPU-"idle" by Task Manager standards yet makes the entire desktop stutter during any interaction. Users on the linked issues report the same on i9-14900HX and 9950X3D machines — hardware is ruled out. Fully exiting the app (not minimizing) stops it instantly; no in-app setting mitigates it.

Mitigations measured locally (partial)

  • Pointing the git-pinned MCP entry at a locally installed exe (uv tool install git+…@<tag> once, then command = <local exe>) removes the per-spawn network fetch + unpack + two wrapper processes → each unavoidable wave is markedly cheaper. This suggests the app could cache/reuse resolved MCP environments the same way.
  • Nothing user-side prevents the kill/respawn cycling itself.

Asks

  1. Reuse long-lived MCP server processes across threads instead of tearing down and re-spawning the fleet per thread lifecycle event (or at minimum, debounce/pool).
  2. Manage child lifetimes with job objects rather than per-PID taskkill /T /F storms (which also leak descendants when wrappers die first — see the 26.611–26.715 reports of orphaned multi-GB Node/Python fleets).
  3. Cache resolved wrapper environments (uvx/npx) so a git-pinned MCP server is not re-resolved over the network on every spawn.
  4. Preserve user MCP enabled state and project-level .codex/ config across Store updates.
  5. Revisit the WMI/telemetry polling cadence documented in #29949 — it compounds with the spawn churn under Defender real-time scanning (exclusions documented ineffective in #33711).

Happy to provide the raw sampler timelines (500 ms and 1 s resolution), the taskkill process-creation records with parent chains, and the timer-stall correlation data.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 21 days ago

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

  • #36176
  • #36258

Powered by Codex Action

giufog · 20 days ago

Confirming the same regression on Windows 10 22H2 with the exact same Store package: OpenAI.Codex 26.803.5235.0.

This machine used the same projects, active-thread set, and workflow without system-wide CPU/RAM saturation until the recent desktop update (approximately two days before this report). The regression began immediately after the update; it is not explained by a change in user workload.

Hardware

  • ASUS N76VZ
  • Intel Core i7-3610QM (4C/8T)
  • 16 GB dual-channel DDR3L-1600
  • Intel HD Graphics 4000 + NVIDIA GeForce GT 650M 2 GB (muxless Optimus)
  • Windows 10 Home 22H2, build 19045

Current live measurements

Three-second sample, percentages normalized to total system CPU:

  • Total ChatGPT/Codex process group: 69.4% CPU, about 3.0 GB working set
  • ChatGPT renderer 1: 19.9% CPU, about 1.1 GB RAM
  • bundled codex.exe app-server: 19.1% CPU, about 481 MB RAM
  • ChatGPT renderer 2: 17.3% CPU, about 703 MB RAM
  • ChatGPT main process: 12.6% CPU, about 446 MB RAM
  • ChatGPT GPU process: only 0.5% CPU, about 134 MB RAM

The desktop app embeds Chromium 151.0.7922.76. The process tree contains three renderer processes plus the GPU, network, storage, audio, crashpad, and app-server processes. Two renderers and the app-server remain simultaneously hot.

GPU observations

  • Windows Graphics preference for the current ChatGPT executable is set to High performance (GpuPreference=2)
  • Hardware acceleration is enabled
  • Renderer command lines show --num-raster-threads=4 and a live --type=gpu-process
  • Task Manager GPU utilization remains at or near 0%; sampled GPU-process CPU was 0.5%
  • The GPU process loads Intel D3D11 modules; NVIDIA rendering modules were not observed
  • Intel and NVIDIA drivers are installed and healthy; NVIDIA 425.31 is the final compatible Kepler mobile driver for this GPU
  • Launch tests with --force-high-performance-gpu and --enable-gpu-rasterization did not eliminate the CPU saturation

Other corroborating symptoms

  • Microsoft Defender has reached approximately 16.7% CPU while the app is hot
  • logs_2.sqlite has grown to approximately 366 MB
  • Active local session files total approximately 1.8 GB
  • Killing only the hot renderer is not a mitigation: it respawns, rehydrates history, and CPU/RAM climb again
  • Fully restarting the app does not provide a durable improvement
  • CLI was upgraded independently to 0.147.0; the desktop package still launches its bundled app-server runtime

Please treat this as an application regression. The user explicitly wants to keep the same desktop UI and the same workflow that worked before the update. Archiving more threads, changing surfaces, or reducing normal usage is not an acceptable substitute for fixing the regression.

Areas that appear worth investigating:

  1. renderer/app-server work that continues after the visible action completes;
  2. MCP/process-manager kill/respawn or live-PID polling;
  3. full conversation snapshot fan-out / repeated history hydration;
  4. Defender amplification from process and cache churn;
  5. why the GPU process remains effectively idle while both renderers saturate the CPU;
  6. a supported Windows switch to suspend background thread/process monitoring and bound history rendering without changing user workflow.

No private logs or conversation contents are included here.

fnoctis · 13 days ago

Additional reproduction on a newer Windows Desktop build, with a completed thread traced to its MCP session.

Environment:

  • Codex Desktop: 26.810.6296.0 (Microsoft Store)
  • Bundled CLI/core: 0.148.0-alpha.9
  • Windows 11 x64
  • High-end workstation; system-wide pointer hitching also occurs with the built-in touchpad, so this is not a USB mouse/driver issue.

Observed:

  • A completed marketplace/browser-automation thread had not spawned any subagents.
  • Its transcript contained 27 calls to the bundled mcp__node_repl__js tool for Chrome control.
  • After the thread completed and was idle, its task-scoped process tree remained alive:

``
node_repl.exe
├─ codex.exe app-server --listen stdio://
└─ node.exe ...\kernel.js --session-id <redacted>
``

  • The kernel command line still referenced the completed thread's isolated worktree. The tree was inactive during sampling (no measurable CPU/disk/network), but still retained processes, threads, handles, and memory.
  • The main Codex app-server also had 11 node_repl.exe children at the time of inspection, plus repeated pairs of Node MCP helper processes (server.cjs --stdio / server.bundle.mjs) created at different thread start times.
  • The main desktop process continued using about 3.9% total CPU on a 32-logical-processor machine (roughly 1.25 cores) even after the heaviest thread had completed.
  • Disabling an unrelated virtual display driver did not eliminate the hitching.

Attribution:

  • This reproduction does not point to subagents: none were spawned by the completed thread.
  • It does point to the bundled Node REPL / browser-control MCP lifecycle: the MCP was legitimately used, but Codex did not reclaim the task-scoped Node REPL/app-server/kernel tree when the owning thread reached a terminal state.
  • The MCP itself was not actively consuming CPU when sampled, so the likely defect is ownership/cleanup (and possibly accumulated app-level polling/handles), rather than a user script still running.

Expected:

  • On completed/cancelled/failed thread state, close the MCP stdio session and associated kernel/app-server tree, or return it to a bounded shared pool with an idle timeout.
  • Expose a user-facing “reset runtimes / clean stale helpers” action so recovery does not require fully exiting the desktop app.

I can provide a sanitized process snapshot and session transcript metadata if maintainers need them.

Alex870 · 7 days ago

Additional reproduction/evidence on Windows Desktop 26.803:

I’m seeing the same system-wide performance failure when using Codex Desktop. On my Intel Core i9-13900K, submitting a prompt—even in the current chat—or switching chat contexts causes total CPU usage to reach 100% for approximately 30–45 seconds. The entire system becomes difficult to use: mouse movement, typing, and other applications lag or freeze.

The problem is strongly interaction-triggered:

  • Starting Codex can trigger it.
  • Switching between existing chats can trigger it.
  • Sending a prompt in an already-open chat can trigger it.
  • Codex is relatively quiet while left idle.

Local process sampling shows the Codex processes are mostly idle between spikes, so a delayed snapshot can miss the event. However, the Codex sandbox log shows repeated helper initialization:

codex.exe --codex-run-as-fs-helper

These launches are followed by repeated sandbox setup and ACL refresh operations. The same error repeats:

hide users: failed to hide current user profile dir
C:\Users\Default
SetFileAttributesW failed ... Access is denied

The relevant log is:

C:\Users\<USER>\.codex\.sandbox\sandbox.2026-08-20.log

The log contains hundreds of helper starts, including bursts where several helpers launch within roughly one second. This appears consistent with sandbox/MCP/runtime teardown and respawn churn during chat navigation or prompt submission.