[Bug] Agent-status intents are routed to placeholder shell output, causing a tool-selection loop

What issue are you seeing?

During a long-running Codex App task that uses visible subagents, the coordinator can enter a tool-selection loop while trying to check or wait for subagent state.

The intended actions are collaboration tools such as:

• collaboration.list_agents
• collaboration.wait_agent
• collaboration.followup_task
• collaboration.spawn_agent

Instead, the trace shows the coordinator selecting the PowerShell shell tool and emitting placeholder commands such as:

Write-Output 'list_agents'
Write-Output 'actual now'
Write-Output 'why am I stuck'
Write-Output 'seriously'
Write-Output 'after this'
Write-Output 'ok'
Write-Output 'a'
Write-Output 'b'
Write-Output 'c'

These commands complete successfully but have no relation to agent state and do not advance the workflow. The coordinator then attempts another placeholder shell command, producing a self-sustaining loop. The issue is not a PowerShell Write-Output failure; the problem is that an agent-state/tool-routing intent is being sent to an unrelated shell tool.

What steps can reproduce the bug?

1. Start a fresh Codex App task on Windows with visible subagent collaboration enabled.
2. Ask the coordinator to create a detail worker and then use only collaboration tools to verify the worker state and wait for its result. For example:

``text
Create a visible subagent to process the assigned detail batch.
After dispatch, call collaboration.list_agents and confirm it is running.
Use collaboration.wait_agent to wait for completion.
If it is pending_init, re-dispatch it or create a new visible subagent.
Do not use shell commands or terminal polling for agent status.
``

1. Let the worker remain incomplete for at least one wait interval, or send a follow-up such as continue while the worker is pending.
2. Observe the coordinator's emitted tool calls. In the affected run, the intended collaboration calls are replaced by shell_command calls containing Write-Output placeholders.
3. The shell calls return normally, after which the coordinator repeats the same pattern instead of querying or waiting for the agent.

What is the expected behavior?

The coordinator should emit the requested collaboration tool directly:

collaboration.list_agents({})
collaboration.wait_agent({"timeout_ms": 30000})

After a timeout or pending_init state, it should continue with collaboration.wait_agent, collaboration.followup_task, or collaboration.spawn_agent, and then report a concrete blocker if those tools are unavailable.

It should never substitute shell_command/PowerShell output for an agent-state operation. A tool validator or routing guard should reject an unrelated shell call when the preceding intent is to inspect or wait for a subagent.

Additional information

Environment observed in the affected task:

• Platform: Windows 11, Microsoft Windows NT 10.0.26200.0
• Codex CLI: codex-cli 0.146.0
• Surface: Codex Desktop App
• Workflow: parent coordinator waiting for a visible detail subagent
• No source files were changed by the placeholder commands.
• The loop prevents reliable parent/subagent orchestration, wastes turns and tokens, and can leave a long-running workflow neither progressing nor terminating.
• This behavior may be related to tool identity or recipient routing, but the trace alone does not establish whether the owning layer is model tool selection, constrained decoding, the agent runtime, or the app tool registry.

Related issues:

• #35620 reports Agent V2 emitting exec/wait instead of consecutive spawn_agent calls.
• #37113 reports agent wait requests being routed to unrelated functions.wait calls.

This report is narrower and distinct: the incorrect outlet is a shell command containing natural-language placeholders, and the resulting successful no-op calls cause an explicit repetition loop.

Please inspect collaboration-tool routing/selection after a subagent dispatch and consider adding telemetry and a guard against unrelated shell-tool substitutions.