multi_agent_v2 causes subagents to loop on MCP resource listing instead of completing simple tasks

What issue are you seeing?

When multi_agent_v2 is enabled in Codex config, a spawned subagent can fail to complete even a trivial task and instead appears to loop on MCP listing calls.

Observed behavior:

• subagent creation succeeds
• task dispatch succeeds
• the parent agent waits until timeout
• the subagent does not return the requested final response
• in the UI, the subagent repeatedly invokes MCP listing tools such as List MCP Resources and List MCP Resource Templates
• the stuck subagent has to be manually closed
• the subagent view also showed text that looked like parent-agent orchestration commentary rather than a normal child-agent response

A minimal example was a subagent instructed to return exactly one line: PONG. Instead of replying with PONG, it appeared to enter the MCP tool loop.

What steps can reproduce the bug?

1. Enable multi_agent_v2 in Codex config.
2. Spawn a subagent with a minimal instruction such as:

Reply with exactly one line: PONG

1. Do not require any file reads, file writes, tests, or git operations.
2. Wait for the subagent result from the parent agent.
3. Observe that the subagent does not return PONG, the parent wait times out, and the UI shows repeated MCP listing calls instead.
4. Also observe that the subagent view may display text resembling the parent agent's own narration instead of an isolated child response.

What is the expected behavior?

The subagent should immediately return the requested one-line response:

PONG

It should not call unrelated MCP listing tools for this task, and the parent agent should receive the final result without timing out.

The subagent view should also reflect the child task itself, not surface what looks like parent-agent orchestration commentary as though it were the child agent's own output.

Additional information

Environment

• OS: Windows 11 (10.0.22631)
• Shell: PowerShell 7.6.0
• Codex CLI: 0.118.0
• Config difference observed locally:
• works: multi_agent enabled, multi_agent_v2 disabled
• fails: multi_agent_v2 enabled

Logs / screenshots

Textual observations from the failing run:

• parent-side wait_agent timed out while waiting for the subagent result
• the subagent UI repeatedly showed MCP listing activity instead of producing a final reply
• repeated calls included:
• List MCP Resources
• List MCP Resource Templates
• the subagent view also showed this Chinese sentence:

我已经把第二个测试压缩成"只返回一行 PONG"的最小任务；接下来只看它能不能把结果稳定回传，不涉及仓库文件和执行负担。

That sentence reads like parent-agent orchestration commentary, not like something a child agent should independently say for a one-line PONG task.

I used fork_context, so some inherited context is expected. However, surfacing what appears to be parent-style narration in the child-agent view still seems abnormal and may indicate context or message leakage in the multi_agent_v2 runtime/UI path.

A screenshot is already attached in an issue comment.

Possible regression

This looks specific to the multi_agent_v2 runtime or orchestration path rather than the task itself.

As a control comparison, with multi_agent_v2 disabled and regular multi_agent behavior used instead, the same kind of simple subagent task does not exhibit this problem.