›_ Codex Issues
Codex Issues / #33946

[Windows] Multiple Codex tasks duplicate MCP processes and cause system-wide input lag

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

Bug description

On Windows, creating multiple Codex tasks causes local MCP/app-server processes to be initialized repeatedly. The resulting process and console-host explosion makes the entire system extremely sluggish: typing in other applications becomes delayed, normal window operations stutter, and the machine sometimes produces repeated short beep sounds.

Reproduction

  1. Restart Windows.
  2. Launch the Codex desktop app with the existing global MCP configuration.
  3. Create three new Codex tasks/windows.
  4. Continue using another application while Codex remains open.
  5. Observe the process counts and system responsiveness.

Observed behavior

After restart, before creating the additional tasks:

  • Node MCP processes: 5
  • Python MCP processes: 4
  • conhost.exe processes: 9
  • Total processes: approximately 337

As three new Codex tasks/windows were created, monitoring showed:

  • Node MCP processes: 5 -> 15 -> 25 -> 35
  • Python MCP processes: 4 -> 12 -> 20 -> 28
  • conhost.exe processes: 9 -> 91, later peaking at 607
  • Total processes peaked at approximately 1,552
  • CPU usage peaked at 66.76%
  • Processor queue peaked at 94
  • Context switches peaked at approximately 133,693/second

Each new task appeared to add approximately two complete copies of the local MCP set.

The system became difficult to use even when no large task was actively running. Typing in other applications was delayed and the Codex app occasionally became unresponsive.

Environment

  • OS: Windows
  • Codex desktop package observed: 26.715.3651.0
  • Global configuration: 11 MCP servers
  • 9 local stdio servers (5 Node-based and 4 Python-based)
  • 1 local node_repl
  • 1 HTTP server for OpenAI developer documentation

The configuration/control-plane check found no invalid providers, duplicate registrations, missing source paths, or malformed configuration entries.

Additional observations

  • The OpenAI developer documentation MCP endpoint sometimes failed to connect and retried; this may be an additional amplifier but does not explain the process multiplication by itself.
  • During the clean three-task measurement, no workspace files were continuously written.
  • DPC latency was low (approximately 0.36%), and disk latency was low, so the primary symptom appears to be process/scheduling pressure rather than an audio, GPU, or disk bottleneck.
  • The suspected cause is per-task duplication of MCP/app-server initialization and related command-runner/Git-watcher processes. This is a hypothesis based on process-count correlation, not a confirmed internal implementation detail.

Expected behavior

Opening multiple Codex tasks should keep MCP/app-server processes bounded and should not cause system-wide input lag or severe process creation pressure.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32797
  • #32942
  • #32997

Powered by Codex Action

i0switch · 1 month ago

I reproduced the same issue on Windows with a deterministic Open in New Window trigger and collected ETW/process-tree evidence.

Environment

  • Codex Desktop 26.715.4045.0
  • Windows x64
  • Only the current official Codex main/app-server generation was present during the recurrence
  • A legacy Codex installation and CodeGraph were both absent during this recurrence

Reproduction

  1. Start Codex Desktop with several local command/stdio MCP entries enabled.
  2. Right-click a task and choose Open in New Window.
  3. Capture a 1-second system/process monitor and WPR/ETW trace while the new window initializes.

Observed in a 138.69-second trace

  • System CPU: avg 88.8%, p95/max 100%
  • Processor queue: avg 11.1, p95 52, max 69
  • Codex process CPU: p95 764%, max 774%
  • Local Node process count: max 42
  • Codex Responding=False observed
  • Maximum input delay: 7.922s
  • Maximum UI message-check delay: 8.203s
  • ETW flags included HasGhosted and IsSpinning
  • ETW lost buffers: 0

The window action produced two distinct MCP startup waves. One configured MCP used npx, creating cmd -> npx Node -> cmd -> server Node chains. Defender scanning, renderer/GPU work, app-server work, and the duplicated MCP startup burst saturated all logical CPUs. Disk latency and DPC/ISR measurements did not explain the stall.

A/B result and workaround

  • The recurrence happened with the legacy Codex copy absent and CodeGraph absent, so neither explains this official-app path.
  • Moving the heavy local stdio MCPs behind one shared HTTP gateway, and replacing the npx-launched server with a pinned direct Node entry, removed the duplicated heavy-process burst.
  • Three post-change Open in New Window trials recorded Responding=False=0 and heavy local stdio MCP count 0; only bounded 2-3 second transient load remained.
  • A 60-minute post-change monitor (3,601 samples) recorded Responding=False=0, gateway/policy failures 0, and no process-generation changes.

This supports #33946 as a Codex Desktop MCP lifecycle/resource-bounding defect: local stdio MCP pools are started per task/window without sufficient pooling, lazy startup, or burst limits, and the resulting initialization wave can block system-wide input on Windows.

I can provide sanitized ETL and process-tree summaries if maintainers want them.

i0switch · 1 month ago

Follow-up after moving heavy local stdio MCPs behind the shared gateway:

Residual reproduction with heavy stdio count = 0

A later controlled Desktop-tooling trial started from:

  • built-in node_repl processes: 24
  • gateway sessions: 36
  • heavy local stdio processes: 0

One tiny-task creation request returned a deferred tool error, after which 5 tiny tasks were observed. This is an API/tooling-path reproduction; I am not claiming that one manual UI action always creates five tasks.

Within 36 seconds of the request, the 1-second monitor observed:

  • 6 Codex windows hung for 2 seconds
  • system CPU 76.17% -> 92.35%
  • processor queue 0
  • input-proxy delay 4.17 / 5.48 ms
  • physical input idle for about 29 minutes
  • inventory-cached node_repl=29

The before/after markers later reached:

  • node_repl: 24 -> 36
  • gateway sessions: 36 -> 84

The tasks were archived without terminating any process. Counts recovered naturally from 31/64 to 25/40, but were still +1 node_repl / +4 sessions above the 24/36 baseline at 02:32 JST.

A separate 480-second post-trial monitor with node_repl=31 stable recorded:

  • trigger: 0
  • hung windows: 0
  • maximum input-proxy delay: 15.40 ms
  • heavy stdio: 0

A real WinForms mouse + SendKeys round trip recorded:

  • mouse click: 98.8 ms
  • first text event: 801.775 ms
  • full 22-character delivery: 852.191 ms
  • exact text match: yes

Evidence limits

  • Gateway-session growth is only bracketed by the before/after markers; its exact timestamp is unknown.
  • The node_repl value in the hang row came from the periodic inventory cache.
  • The top-process snapshot began about 5 seconds after the trigger, so it is post-trigger evidence rather than an exact simultaneous attribution.
  • The custom ETW trace was not captured because elevation consent was canceled.

So this is a time-correlated candidate mechanism, not final internal attribution. It does add evidence that lifecycle/reclamation pressure can remain in the built-in node_repl/gateway path even when duplicated heavy local stdio MCP processes are already eliminated.

Marco6-3 · 13 days ago

I can reproduce/corroborate this on a newer Windows desktop build.

Environment

  • Codex / ChatGPT desktop package: OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0
  • Windows 11 Home Chinese, build 26200
  • 31.26 GB physical RAM
  • Hybrid GPU: AMD Radeon 780M + NVIDIA GeForce RTX 5060 Laptop GPU

Observed behavior

After the recent Codex update, the Windows desktop becomes noticeably laggy when Codex has several active tasks/processes. This is system-wide stutter, not just a slow Codex window.

The correlation has been confirmed locally: normal work remains responsive before Codex expands into multiple renderer/task/helper processes; the lag appears once those Codex processes are active.

At a live affected snapshot:

  • 10 ChatGPT.exe processes: about 2,736 MB total working set / 2,629 MB private memory
  • codex.exe app-server: about 322 MB working set
  • 3 Node MCP processes
  • 9 node_repl.exe helper processes
  • 2 PowerShell helper processes

This was not ordinary RAM exhaustion:

  • Available physical memory: about 18.4 GB
  • Committed memory: about 18.3 GB / 52.9 GB commit limit
  • Nonpaged pool: about 1.12 GB

Opening Chrome was once observed to make the stutter appear more obvious, but the reproducible underlying correlation is Codex process/task expansion, not Chrome itself. Closing unrelated applications did not reliably restore responsiveness.

Please investigate per-task process duplication/retention and Windows scheduling or input-lag effects in the current desktop package.

Migueldos2 · 9 days ago

Confirmed on Codex Desktop for Windows version 26.814.5167.0.

Environment:

  • Surface Pro 10 for Business
  • Windows 11, build 26200, x64
  • 64 GB RAM
  • Global configuration contains two Home Assistant STDIO MCP servers

Observed:

  • Codex spawned 16 uvx.exe and 16 uv.exe processes for the same ha-mcp@latest server.
  • Process-tree inspection traced the duplicated instances through PowerShell directly to the same codex.exe app-server process.
  • Terminating 30 matching processes reduced the count to zero, but they were recreated after continuing to use Codex.
  • The retained processes locked the installed uv.exe, causing a Winget update to fail with remove: Access is denied.
  • Codex became unresponsive and Windows displayed “Codex is not responding”.
  • Text selection and mouse/UI response were delayed by several seconds.
  • The computer remained stable when Codex was closed.
  • Testing with and without the Surface dock made no difference.

This strongly supports an MCP process-lifecycle/resource-retention issue in the Windows desktop app rather than a problem with the MCP server itself.