[Windows App 26.825.6671.0] Subagents ignore disabled MCP configuration and retain eagerly started MCP process stacks

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

26.825.51511

What subscription do you have?

Pro 20x

What platform is your computer?

No response

What issue are you seeing?

Codex Desktop starts a complete local stdio MCP process stack for every subagent even when the subagent never invokes those tools and its agent profile explicitly disables the MCP servers.

Environment:

• Codex Desktop 26.825.6671.0
• Native Windows x64
• Multi-agent wave containing 8 subagents

The ordinary default, worker, and explorer profiles explicitly disabled the affected servers:

[mcp_servers.codebase-memory-mcp]
command = "cmd.exe"
args = ["/d", "/c", "exit", "0"]
enabled = false

[mcp_servers.node_repl]
command = "cmd.exe"
args = ["/d", "/c", "exit", "0"]
enabled = false

[mcp_servers.sequential-thinking]
command = "cmd.exe"
args = ["/d", "/c", "exit", "0"]
enabled = false

Despite these overrides, after all subagents completed and no corresponding MCP tools were active, process-tree inspection found:

• 39 node.exe descendants of Codex app-server processes
• 11 node_repl.exe descendants
• 9 codebase-memory-mcp.exe processes: one shared daemon and eight stdio frontends
• The current Desktop app-server alone retained 19 Node processes and 6 Node REPL processes
• Several Codebase Memory frontends accumulated approximately 2,500–6,200 CPU-seconds

Sequential Thinking is configured globally through:

command = "npx"
args = ["-y", "@modelcontextprotocol/server-sequential-thinking"]

Every subagent appears to initialize another npx wrapper and actual MCP server without using the tool. Completed subagents do not dispose the resulting process trees.

What steps can reproduce the bug?

1. Configure several local stdio MCP servers globally, including Node REPL and an npx-based server.
2. Explicitly disable those servers in ordinary subagent profiles.
3. Start Codex Desktop and spawn several subagents.
4. Give them tasks that never call MCP tools.
5. Wait for all subagents to complete.
6. Inspect descendants of the long-lived Codex app-server process.

What is the expected behavior?

• Per-agent enabled=false is honored before any process is created.
• Unused MCP servers start lazily on first tool invocation.
• Every MCP child process is terminated when its owning subagent completes.
• Shareable services are pooled instead of receiving one frontend per subagent.

Additional information

Each subagent eagerly receives another MCP stack, and completed subagent processes remain resident. CPU and memory usage therefore grow with every agent wave until Codex is restarted or processes are terminated externally.

Related reports:

• https://github.com/openai/codex/issues/38693
• https://github.com/openai/codex/issues/34658
• https://github.com/openai/codex/issues/28935
• https://github.com/openai/codex/issues/21984

This report is separate because it reproduces on the current Windows build and shows that explicit per-agent enabled=false overrides do not prevent eager process creation.

Start by tracing MCP initialization and process teardown in the Codex Desktop app-server and its subagent lifecycle, reproducing the Windows process tree described in the issue. Done means disabled servers create no processes, unused servers start only on tool invocation, and MCP child processes terminate when their subagent completes; verify with the multi-agent reproduction.