[Windows][CLI 0.146.0] MultiAgentV2 custom-agent spawn ends the parent after child task_started with zero model events

What version of Codex CLI is running?

codex-cli 0.146.0

What subscription do you have?

ChatGPT subscription. The exact tier is not exposed by the local diagnostics used for this report.

Which model were you using?

Parent: gpt-5.6-sol, reasoning effort high.

Child custom role: gpt-5.6-luna, reasoning effort high.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

Hardware:

• CPU: AMD Ryzen 5 PRO 4650G with Radeon Graphics
• CPU topology: 6 physical cores / 12 logical processors
• Maximum reported clock: 3700 MHz
• Installed physical memory: 16 GB nominal (15.41 GiB reported by Win32_ComputerSystem)
• Configured page file: 22,528 MiB

The exact free physical-memory value at the failure timestamp was not sampled, so I am not claiming a historical free-RAM number.

The current Windows boot started at 2026-07-26 10:54:31 +09:00, before the affected run, and had not restarted when this evidence was collected. Win32_PageFileUsage reported a peak usage of 3,853 MiB out of the configured 22,528 MiB page file during that boot.

For the exact incident window, 2026-07-30 02:55–03:05 +09:00, Windows Event Log contained:

Resource-Exhaustion-Detector event 2004: 0
Application Error / Windows Error Reporting events matching codex.exe, node.exe, powershell.exe, or pwsh.exe: 0
Kernel-Power 41 / unexpected shutdown 6008: 0

The parent and child rollouts also contained no out of memory, allocation failure, panic, or fatal event. This rules out Windows-detected resource exhaustion as an observed cause, but it does not prove that transient memory pressure was impossible.

What terminal emulator and version are you using (if applicable)?

Interactive Codex CLI/TUI launched from PowerShell 7.6.4 (pwsh.exe, PowerShell Core).

Codex doctor report

{
  "reportRedacted": true,
  "overallStatus": "warning",
  "codexVersion": "0.146.0",
  "authMode": "chatgpt",
  "modelProvider": "openai",
  "configuredMcpServers": 10,
  "configuredStdioMcpServers": 10,
  "configParse": "ok",
  "stateDbIntegrity": "ok",
  "providerHttpReachability": "ok",
  "responsesWebSocketHandshake": "ok",
  "latestVersion": "0.146.0"
}

The full report contains local paths and can be provided in a separately sanitized form if needed. Its warning was about four historical rollout files with unusable headers, not the affected parent or child rollouts.

What issue are you seeing?

Spawning one configured MultiAgentV2 custom agent can terminate the parent CLI session during child startup.

I reproduced this twice with the same custom role and task name. In both failures:

• spawn_agent returned a child registration.
• The child rollout contained exactly session_meta followed by one event_msg/task_started.
• The child produced zero response items and zero token usage.
• The two rollout timestamps were only 1 ms apart.
• The parent proceeded to wait_agent.
• The parent rollout then ended without a wait_agent output, task_complete, turn_aborted, panic, or fatal event.
• The interactive Codex process disappeared and PowerShell regained control without a useful diagnostic.

One concrete pair:

parent thread: 019faef6-aab2-7cc3-b2ba-d6a0cc9d9c68
child thread:  019faf08-3c1c-7171-a15c-eccf553573c1
agent path:    /root/hands_on_qa
agent role:    lazycodex-qa-executor

The parent's last durable records were:

spawn_agent function call
sub_agent_activity
spawn_agent function output
token_count
world_state
reasoning
wait_agent function call
<rollout ends; no output or terminal event>

The child's complete event sequence was:

session_meta
event_msg/task_started

I then ran an A/B control on the same Codex version, role, model, task name, and local application:

• disabled plugins, plugin hooks, hooks, and apps in the child profile;
• disabled every inherited stdio MCP server except the one required for the browser QA scenario;
• restarted in a fresh parent session;
• spawned the same role once.

The control child completed normally, returned its real browser/API QA result, produced 98 response items, and reached task_complete.

This does not isolate one specific MCP server because the control reduced several child startup layers together. It does localize the failure to the child's inherited MCP/plugin/app/hook startup surface rather than the task name, QA prompt, application source, or gpt-5.6-luna generally.

No application source files or remote service state were changed during the failed reproductions or the read-only control.

What steps can reproduce the bug?

1. On Windows, use standalone codex-cli 0.146.0 with ChatGPT auth and MultiAgentV2 enabled.
2. Configure several local stdio MCP servers globally. The affected environment had 10.
3. Register a custom child profile:

``toml
name = "qa_probe"
description = "Read-only QA probe"
model = "gpt-5.6-luna"
model_reasoning_effort = "high"
developer_instructions = """
Run the assigned read-only QA scenario and return evidence.
Do not modify source files or remote state.
"""
``

1. From an interactive gpt-5.6-sol parent, make exactly one spawn:

``json
{
"task_name": "hands_on_qa",
"agent_type": "qa_probe",
"fork_turns": "none",
"message": "Run the supplied read-only local UI and API checks, then return evidence."
}
``

1. Wait for the child with wait_agent.
2. In affected runs, observe the child rollout end immediately after task_started, then the parent rollout end on the wait_agent call with no terminal diagnostic.
3. As a control, add child-profile overrides that disable optional features and all inherited MCP servers except one required server, restart Codex, and repeat the same spawn. In my environment the child then completed.

The exact public MCP packages are not required to state the invariant: the parent should survive any child startup failure and receive a bounded structured error. I can provide a sanitized server inventory privately if maintainers need the same startup mix.

What is the expected behavior?

• A child that fails during MCP/plugin/app/hook initialization should transition to a structured terminal state such as startup_failed.
• spawn_agent or wait_agent should return the failing startup component and error.
• The parent CLI/TUI must remain alive and recoverable.
• The child rollout should include a terminal failure event rather than ending after task_started.
• A child startup failure must not leave ambiguous persistent spawn state or unreaped child process groups.

Additional information

Closest existing reports are related but do not contain this full failure shape:

• #19542: Windows custom subagent hangs during MCP startup. Here the child does not hang; its rollout stops immediately and the parent exits.
• #32974: Windows CLI silently exits while waiting on a tool. Here the direct trigger is a single custom-agent spawn and child startup.
• #32975: multi-server cold start can cancel an active Codex App task. This reproduction is the standalone CLI/TUI.
• #33231: a child rollout can contain only session_meta and task_started. That report remains in progress indefinitely; this child and parent terminate.

The successful control also left one additional Playwright MCP process stack and an open thread_spawn_edges row after task_complete. I treated that as corroborating evidence for the already reported cleanup family rather than a second new bug; see #34658 and #33700.

I compared this with current upstream source at commit 85c082ccccf6b5ac4d6c31d14f960057348b78f4. Session initialization still publishes the per-session MCP runtime and validates required servers before normal task execution. The MultiAgentV2 spawn path registers the child and sends the initial communication before returning, while wait_agent waits for parent mailbox/steer activity or timeout; terminal children can remain resident until an eviction/close boundary. I am not claiming a source-level root cause for the parent exit, only that the black-box A/B points to child startup and that the parent lacks a safe error boundary there.

Suggested diagnostic/fix boundary:

1. Add a bounded child-startup phase and explicit startup_failed event.
2. Catch MCP/plugin/app/hook initialization failure at the spawned-thread boundary.
3. Always resolve the parent's pending spawn_agent/wait_agent call with a structured error.
4. Record the child startup component, exit reason, and teardown outcome before removing or retaining the child.
5. Add a Windows regression test where a custom child has multiple stdio MCP servers and one startup path fails or is cancelled; assert that the parent remains alive and the child has a terminal event.

---
This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated

/root/inspect_workspace
/root/video_metadata

code-mode host closed its stdout

parent:
019fdc8e-0c88-7db2-b69b-01c1e6f6374f

child 1:
019fdc8f-27e9-7bb3-8b89-539392e0aee2
agent path: /root/inspect_workspace

child 2:
019fdc8f-461c-7153-b622-b7375ee608ad
agent path: /root/video_metadata

spawn_agent(/root/inspect_workspace)
spawn_agent output
spawn_agent(/root/video_metadata)
spawn_agent output
custom_tool_call(exec)
custom_tool_call_output("code-mode host closed its stdout")
<rollout ends without a final or terminal event>

session_meta
task_started
model/reasoning events
custom_tool_call(exec)
custom_tool_call_output("code-mode host closed its stdout")
<rollout ends without a terminal result>