[Windows][Codex App 26.707.9564.0] app-server restarts and cancels MCP tasks during multi-server cold start without a crash diagnostic

Codex App version

26.707.9564.0

Operating system

Windows 11 Pro x64, build 26100.7171

What happened?

During a long-running, multi-agent Codex App task that uses three local MCP servers, the App intermittently lost the active task during a cold-start / process-replacement window.

In the affected window (2026-07-13 13:16-13:19 local time), the local Codex logs showed:

• rapid replacement of the app-server process;
• the replacement process issuing standard tools/list requests to all three MCP servers;
• each server returning a tool catalog of roughly 76 KB;
• the active MCP task then being cancelled;
• RunningService dropped without explicit close.

The task did not reach its terminal event, so work that was already in progress had to be recovered manually from durable project receipts. Windows Application Event Log / WER did not provide a uniquely attributable Codex crash record for the same time window.

I am reporting the CLI silent-exit symptom separately in #32974. This issue is specifically about Codex App host/app-server continuity and diagnostics when multiple MCP servers and multi-agent work are active.

Expected behavior

• A transient app-server restart or MCP cold-start should not discard the active task.
• The App should admission-control or stagger expensive MCP catalog initialization when necessary.
• Work should resume from durable state after a worker/app-server replacement.
• If the host or worker exits, the App should preserve an explicit reason, exit code, and component-level diagnostic instead of only leaving cancellation / dropped-service messages.

How to reproduce

This is intermittent rather than a minimal deterministic reproduction:

1. On Windows, configure three local stdio MCP servers with non-trivial tool catalogs.
2. Start a long-running task with multi-agent work and local MCP calls.
3. Allow the App to cold-start or reconnect the three MCP servers.
4. Observe app-server process replacement and concurrent tools/list activity.
5. In the affected runs, the active MCP task is cancelled and RunningService dropped without explicit close is logged, with no actionable WER record.

Additional context

The evidence supports a combined lifecycle/resource/control-path failure; it does not establish that catalog size, PowerShell/WMI activity, or any one MCP server is the sole root cause.

This has high impact for long-running engineering tasks because the task can disappear after substantial verified work, leaving a partially modified local workspace that must be reconciled by hand.

For local mitigation I am currently:

• starting a fresh CLI process rather than resuming the affected process;
• loading one MCP instance only;
• disabling optional Apps and per-process Hooks;
• using durable checkpoints and external gate receipts;
• limiting simultaneous shell-heavy subagents.

I can provide the sanitized app-server log excerpt and timestamps privately if maintainers need them.