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

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.