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

[mychox68]

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:

   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.
   """

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

   {
     "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."
   }

5. Wait for the child with wait_agent.

6. 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.

7. 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:

• Creating sub-agent hangs on MCP startup #19542: Windows custom subagent hangs during MCP startup. Here the child does not hang; its rollout stops immediately and the parent exits.
• [Windows][CLI 0.144.3] Codex silently exits while waiting on a tool after successful auto-compaction / PostToolUse activity #32974: Windows CLI silently exits while waiting on a tool. Here the direct trigger is a single custom-agent spawn and child startup.
• [Windows][Codex App 26.707.9564.0] app-server restarts and cancels MCP tasks during multi-server cold start without a crash diagnostic #32975: multi-server cold start can cancel an active Codex App task. This reproduction is the standalone CLI/TUI.
• Codex Desktop create_thread can leave child task inProgress with zero events indefinitely #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

[mychox68]

Fresh reproduction update from 2026-08-04:

I reproduced the same zero-model-event termination twice more on CLI 0.146.0 / Windows / gpt-5.6-sol.

New evidence strengthens and slightly revises the scope in the original report:

• Failure A was a second sequential child after a successful reviewer child.
• Failure B was the first and only child in a fresh parent, with fork_turns: "none".
• Both failed children used a registered lazycodex-gate-reviewer role on the same OpenAI provider.
• In each failure the child had one durable open edge, tokens_used=0, and a rollout containing only session_meta + task_started.
• Each parent rollout ended on the subsequent wait_agent function call with no function output or terminal error.
• For the fresh-parent failure, the parent rollout contains exactly one spawn_agent call and SQLite contains exactly one edge, but the TUI rendered the identical Started /root/<task> activity line twice. The duplicate text is therefore a TUI/event-delivery symptom, not a duplicate model tool call.

Most importantly, I then ran the same fresh-parent / first-and-only-child topology again in the full current environment, without disabling the role or inherited tooling. The child completed normally, directly inspected all 27 assigned PNGs, returned task_complete: REVISE, and the parent received normal wait_agent timeout/activity results.

So inherited MCP/plugin/app startup remains a possible trigger surface, but it is not deterministically required: the identical current environment can both fail at task_started and later succeed. The invariant remains that any child startup failure must be contained and surfaced; it must not silently terminate the parent TUI.

I compared current main at b2dc8b3:

• V2 spawn awaits spawn_agent_with_communication before emitting Started.
• agent control creates/notifies/persists the child, then sends the initial inter-agent communication.
• V2 wait converts timeout/closed watch outcomes to a normal result.
• TUI on_sub_agent_activity appends every received activity cell without an obvious idempotency guard.

A separate issue I opened before rediscovering this report, #36826, contains the same failure and will be closed as a duplicate of this issue.

[mychox68]

Update: still reproducible on Codex CLI 0.147.0 during concurrent code-mode execution

I reproduced the same parent-session termination invariant again on 2026-08-07 with codex-cli 0.147.0.

Environment

• OS: Windows
• Terminal emulator: Waveterm
• Shell: PowerShell
• Codex CLI: 0.147.0
• Parent model: gpt-5.6-sol
• Reasoning effort: high
• Multi-agent enabled
• OMO had been removed before this reproduction and was not installed or present in the execution path.
• No Windows Application Error or Windows Error Reporting event was recorded during the failure window.

This reproduction therefore did not involve OMO. It occurred in a Codex CLI session running in PowerShell inside Waveterm.

What happened

The parent spawned two ordinary subagents:

/root/inspect_workspace
/root/video_metadata

Each spawn_agent function was called exactly once and returned a registered child thread.

Both children progressed beyond task_started. Unlike the original reproduction in this issue, they produced model events and entered code-mode exec tool calls.

The parent was also executing an exec tool call at the same time.

At exactly 2026-08-07T14:10:15.837Z, the parent and both children received the same tool failure:

code-mode host closed its stdout

Immediately afterward:

• the parent produced no final response;
• no task_complete or turn_aborted event was recorded;
• the child threads produced no terminal result;
• the entire interactive Codex CLI returned to the PowerShell prompt;
• no native crash or Windows Error Reporting event was recorded.

Relevant threads

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

Durable event shape

Parent:

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>

Each child:

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>

The UI displayed each Started /root/... label twice, but the parent rollout confirms that each child was spawned only once. This appears to be duplicate activity rendering rather than duplicate spawn_agent calls.

Earlier reproduction during the same workflow

An earlier attempt during the same workflow also terminated shortly after two subagents were spawned. In that attempt, the rollouts ended abruptly before a structured error was persisted.

The second attempt captured the explicit shared error shown above.

Relation to the original report

This is not identical to the original zero-model-event child-startup reproduction:

• Original report: the child stopped immediately after task_started, apparently around inherited MCP/plugin initialization.
• New reproduction: both children completed model work and entered concurrent code-mode tool execution before the shared host closed its stdout.
• New environment detail: OMO was absent; the session was run in PowerShell inside Waveterm.

However, the core failure invariant is unchanged:

A child or shared execution-host failure is not isolated or converted into a structured child error. Instead, the parent CLI session also terminates without a recoverable result.

This suggests that the missing failure boundary may apply more broadly than child startup and also affect a shared code-mode execution host under concurrent parent/child tool use.

Expected behavior

If the code-mode host exits or closes stdout:

1. Each affected tool call should receive a bounded structured error.
2. Child threads should transition to a terminal failed state.
3. The parent should remain alive.
4. The parent should receive the child failures through wait_agent or its mailbox.
5. The CLI should allow retrying, closing the failed children, or continuing serially.
6. The parent rollout should always contain a terminal event instead of silently ending.

Please let me know if this should remain attached to this issue or be split into a separate issue specifically for concurrent code-mode host failure. The rollouts can be provided in sanitized form if needed.