[Windows] spawn_agent dispatch stalls in background and resumes on app activation

What version of the Codex App are you using?

Codex Desktop 26.715.7063.0.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Windows 10 Pro 22H2, build 19045, x64.

What issue are you seeing?

An active long-running persisted goal can stop making progress while Codex Desktop is in the background. A pending spawn_agent call and its child task remained dormant for more than two hours, then resumed as soon as the Windows app was activated again. The child started before a new user message was submitted, so this looks like an app activation / reconnect wake-up rather than the new prompt itself causing the continuation.

This is distinct from a renderer Not Responding issue: during this occurrence Windows and the Codex UI remained responsive. The missing behavior was background agent/tool dispatch.

Sanitized local event timeline (Europe/Brussels):

• 08:49:12: parent rollout records function_call name=spawn_agent.
• 08:49:18: child rollout receives only session_meta; no task_started event follows.
• 08:49:20 and 08:49:22: local Codex logs record codex_rmcp_client::rmcp_client::streamable_http_retry warnings.
• No parent or child rollout events are recorded for the pending dispatch during the following 2h18m.
• Around 11:07: the user returns to and activates Codex Desktop.
• 11:07:31.805: child rollout records task_started.
• 11:07:32.140: parent receives sub_agent_activity and then the delayed spawn_agent function output.
• 11:07:32: local logs record codex_core::responses_retry with connection/disconnected/retry indicators.
• 11:07:54.136: the new user message is registered, about 22 seconds after the child already started.

Windows power evidence for the same interval:

• Active plan: High performance.
• Sleep timeout on AC and DC: Never.
• No Kernel-Power or Power-Troubleshooter sleep/resume event occurred during the gap.
• Task Manager sometimes shows an Efficiency Mode leaf on some Codex/ChatGPT subprocesses. At a foreground snapshot, codex.exe and its MCP children were Normal; two Chromium renderer processes were Idle. I cannot prove EcoQoS state on Windows build 19045, so I am reporting this only as an observation, not as the confirmed cause.

There is also a separate/current MCP lifecycle leak in the same long-lived app-server session: 95 direct node.exe MCP children remained alive (49 mcp/server.bundle.mjs, 46 mcp/server.mjs), using about 6.24 GiB combined. The system still had about 42.6 GiB free, so the dispatch stall was not caused by physical-memory exhaustion. I will add that current Windows data point to the existing MCP leak issue rather than duplicate it here.

What steps can reproduce the bug?

The occurrence is not yet deterministic, but the observed pattern is:

1. Start or continue a persisted /goal in Codex Desktop on Windows.
2. Let the parent turn call spawn_agent while the computer remains awake.
3. Leave Codex Desktop backgrounded for an extended period.
4. A transient MCP/Responses connection retry occurs.
5. The child session is registered but does not receive task_started; the parent remains blocked waiting for spawn_agent output.
6. Activate the Codex Desktop window again.
7. The child starts and the delayed tool result is delivered before any new user message is submitted.

What is the expected behavior?

• Active goals, tool calls, and subagent dispatch should continue while the app is backgrounded and the computer is awake.
• A transient connection failure should retry and resume without requiring window activation, keyboard/mouse activity, or another user message.
• The app-server/agent loop should not depend on Chromium renderer foreground timers or Windows foreground status for reconnect, mailbox delivery, or spawn_agent completion.
• If background execution is intentionally paused, the UI should state that explicitly instead of presenting the goal as autonomously active.

Additional information

Likely areas to inspect, without claiming a confirmed root cause:

• Responses WebSocket reconnect/continuation after a background interval.
• Whether app activation is the only event that pumps a stalled reconnect or pending inter-agent mailbox.
• Electron/Chromium background timer throttling versus the app-server process lifecycle.
• Windows Efficiency Mode/EcoQoS interaction with packaged desktop subprocesses.

Privacy note: this report intentionally excludes project names, repository data, local usernames/paths, thread IDs, prompts, transcripts, and raw logs. Exact redacted diagnostics can be provided privately if requested.