Windows native 26.715: chat resume launches retained MCP stacks, including disabled/unlisted plugins

Codex App version

26.715.4045.0

Platform

Microsoft Windows NT 10.0.26200.0 x64
Native Windows Desktop app-server (not WSL)

Summary

Selecting or reading an existing chat, without sending a prompt or invoking a tool, runs thread/resume and eagerly starts one complete local MCP runtime stack for that chat. These stacks are not reliably released when chats become inactive, so Node processes and memory grow with the number of chats read.

This overlaps strongly with #32154, but this report adds two Windows-native findings:

1. the issue reproduces with the native Windows app-server rather than WSL2;
2. Desktop starts plugin MCP runtimes that are disabled in the current config and absent from both the current plugin list and CLI MCP list, suggesting that the resume path uses a stale per-chat plugin/MCP snapshot or orphan plugin registration.

The user observed that this behavior began after the recent merged Codex/ChatGPT Desktop update. This is a temporal observation only; no pre-update process trace is available, so causality is not proven.

Controlled findings

An initial startup amplifier was identified and removed first:

• Seven long-term heartbeat + target_thread_id automations caused seven simultaneous task resumes at Desktop startup.
• They were converted through the supported automation API to standalone cron automations.
• After a cold restart, the seven-way startup resume burst disappeared.

The underlying per-chat lifecycle issue remained:

• Six distinct resumed chats produced six instances each of:
• node_repl.exe
• Sites node .../mcp/server.mjs
• Data Analytics node .../mcp/server.cjs --stdio
• Creative Production node .../mcp/server.bundle.mjs
• No tool calls were made; merely reading/selecting the chats was sufficient.
• At that point the six retained stacks used approximately:
• Creative Production: 458.2 MB aggregate working set
• Data Analytics: 328.5 MB
• Sites: 318.7 MB
• node_repl: 64.9 MB
• Total: approximately 1.17 GB
• A later trace showed 10 thread/resume events, only 4 thread/unsubscribe events, and 8 complete runtime stacks still resident.
• In Task Manager, each newly read chat visibly added three ordinary Node processes plus a separate node_repl.exe.
• Unrelated background Node processes were excluded using parent-process ancestry; only children of the native Desktop app-server were counted.

Current-config contradiction

For Data Analytics and Creative Production:

• the whole plugins are disabled in the current configuration;
• their nested plugin MCP servers are also explicitly disabled;
• codex plugin list --json does not list either plugin;
• the current CLI codex mcp list does not list either server;
• nevertheless, Desktop thread/resume still launches their cached server.cjs and server.bundle.mjs runtimes.

This makes the issue more than ordinary eager startup of enabled servers. The native Desktop resume path appears to be initializing MCP from an older task/session snapshot or orphan cached registry instead of the current effective configuration.

Steps to reproduce

1. Use Codex Desktop on native Windows with Sites/node_repl enabled and at least one formerly enabled plugin MCP now disabled.
2. Fully exit and cold-start Desktop.
3. Do not send prompts and do not invoke tools.
4. Select several distinct existing chats from the sidebar, waiting briefly after each selection.
5. Correlate thread/resume events with child process creation under the Desktop codex.exe app-server.
6. Navigate away from chats and inspect thread/unsubscribe plus the remaining child processes.
7. Compare the launched servers with the current effective codex plugin list --json and codex mcp list.

Expected behavior

• Reading an idle chat should not start local stdio MCP servers before a turn or actual tool capability needs them.
• At minimum, the number of process-owning MCP managers should remain bounded and inactive zero-subscriber chats should release them.
• Disabled or currently unlisted plugin MCP servers must never launch from a resumed chat.

Actual behavior

• Each newly read/resumed chat starts a full local MCP stack eagerly.
• Cleanup is partial or delayed enough that stacks accumulate and materially slow the machine.
• Disabled and unlisted plugin MCP servers still launch from the Desktop resume path.

Potential fix directions

1. Make local MCP initialization lazy at turn/start or first real tool-capability access rather than thread/read / thread/resume.
2. Detach process-owning MCP managers when an inactive chat reaches zero subscribers, while retaining lightweight chat state.
3. Recompute the effective MCP/plugin configuration on resume, or invalidate old per-chat snapshots when plugin/config state changes.
4. Refuse to launch a cached plugin server when the current plugin registry/config marks it disabled or no longer installed.
5. Add diagnostics mapping each MCP process group to its owning chat/session, current subscriber count, config fingerprint, and teardown status.

Related reports

• #32154 — nearly identical per-opened-chat eager MCP stack retention on Windows/WSL2
• #20883 — proposal for a project-scoped/shared MCP process pool
• #33531 — retained per-runtime MCP suites on Windows

Privacy boundary

No chat contents, thread IDs, account data, local usernames, business paths, credentials, or raw logs are included.