[BUG] Agent Teams: Lead agent requires manual stdin input to process teammate notifications — breaks unattended orchestration

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46691
2. https://github.com/anthropics/claude-code/issues/51167

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate. While the symptoms are similar to #38932 and #46691, this report confirms that the regression persists in v2.1.116 on macOS.

My case provides additional technical evidence:

Visual Proof: The attached screenshots clearly show that the teammate's output is already rendered in the terminal, yet the Lead Agent remains in a "zombie" Idle state. This confirms the deadlock is in the event loop's consumption of the buffer, not in the teammate's execution.

Orchestration Complexity: This occurs during complex handoffs managed by a custom orchestrator submodule ('brain'), showing that current stdin coupling breaks advanced automation workflows.

Version Gap: Reports like #38932 were filed on much older versions. This issue proves that previous fixes have not fully resolved the architectural coupling between the reasoning loop and terminal input events.

Reproduces in claude -p (non-interactive) on v2.1.139 — not limited to Enter/TTY interaction

I hit this on v2.1.139 (macOS) and the symptom set looks broader than the original report suggests. The lead never surfaces queued teammate messages even when there is no TTY/stdin in the picture, so this doesn't appear to be solely a "needs Enter keypress" issue.

Repro

Non-interactive harness via claude -p:

mkdir -p /tmp/t51959 && cd /tmp/t51959
claude \
  --setting-sources project,local \
  --print \
  --permission-mode bypassPermissions \
  --output-format stream-json \
  --include-hook-events \
  --no-session-persistence \
  --model opus \
  --settings '{"env":{"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS":"1"}}' \
  "TeamCreate({team_name: \"t51959\", description: \"probe\", agent_type: \"researcher\"}).
  Agent({subagent_type: \"general-purpose\", team_name: \"t51959\", name: \"a\", model: \"sonnet\", prompt: \"sleep 20; SendMessage to team-lead with exactly 'TOKEN_A'; go idle.\"})
  Agent({subagent_type: \"general-purpose\", team_name: \"t51959\", name: \"b\", model: \"sonnet\", prompt: \"sleep 20; SendMessage to team-lead with exactly 'TOKEN_B'; go idle.\"})
  Then wait up to 90s via Bash sleep calls for both <teammate-message> blocks. Do NOT call SendMessage as a wakeup. Report a JSON with token_a_arrived_as_teammate_message and token_b_arrived_as_teammate_message booleans."

Observed

• Both teammates write tokens to ~/.claude/teams/t51959/inboxes/team-lead.json at ~t0+25s and ~t0+28s (visible by reading the file directly)
• All inbox entries stay read:false through the full 90s wait
• Zero <teammate-message> blocks ever appear in the lead's conversation (verified via stream-json output)
• Agent self-reports verdict: "REPRODUCES_51959". Lead sent 0 wakeup pings (teammates did call SendMessage to write the tokens, but the lead never called it).

Why this looks broader than stdin/TTY

• Repros in claude -p where there is no user keystroke to wait on
• The inbox file shows the entries, but the lead never surfaces them as teammate-message blocks
• The lead's other tool calls (Bash sleeps, file reads, ToolSearch) all fire normally throughout the wait window — only the inbox-to-conversation delivery is dead

I don't know which internal component owns the delivery step, but whatever it is, it isn't being driven during -p mode either.

Monitoring

I've put this probe on a weekly cron — same harness runs every Sunday, classifies the outcome as BUG_REPRO / FIX_DETECTED / HOOK_BLOCKED / UNKNOWN, and writes a ledger row. If two consecutive runs come back FIX_DETECTED, I'll comment back with the CC version that landed the fix.

Happy to share the exact command or a redacted stream-json excerpt if useful.

Environment

• CC v2.1.139 (macOS Apple Silicon)
• opus-4-7 lead, sonnet teammates, in-process backend (no tmux)
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 via --settings flag (verified reaching the spawned process)
• --setting-sources project,local (skips my user-scope hooks so they don't interfere)

the underlying coupling is that the lead agent's loop reads from stdin as a discrete event, so teammate-message blocks don't enter the lead's context until a keystroke pumps the event loop. wrapping claude code outside the terminal (native UI, ACP transport) breaks this assumption: with no stdin in the picture, teammate messages can be injected as context events directly. as long as the lead is bound to a tty you'll keep hitting this in CI and headless flows too. the auto-process flag suggestion sidesteps the architectural piece, which is the real cost.

Here's how I ended up solving this. I moved orchestration out of the model into a small MCP-based layer: a server drives the workflow, validates each transition, and won't let agents skip steps or stall during unattended runs. Every execution is logged, making runs reproducible and auditable.

It fixed the issue for me. Happy to share access if anyone wants to try it — I'd genuinely appreciate feedback or criticism from others building agent workflows.

The manual stdin requirement is the thing that makes Agent Teams impractical for any unattended or scheduled orchestration -- it means your orchestrator has to be interactive, not a daemon.

We ran into this building a scheduled polling runner that dispatches Agent Teams jobs on a cron. The lead session stalls waiting for stdin on the teammate notification path even when there is nothing a human needs to see or respond to -- it is just an internal coordination message. This turns a batch workload into an interactive one, which defeats the purpose.

The MCP-based workaround that Dich01 described (a server driving the workflow and validating transitions) is the right structural fix at the application layer. We went a similar direction: move orchestration state out of the session and into an external coordinator, so the session itself handles execution but does not own the flow. That way the stdin requirement only affects the human-facing entry points, not the internal agent-to-agent handoffs.

Three things that would make this workable at the platform level:

1. A non-interactive mode flag for the lead session -- something like CLAUDE_CODE_AGENT_TEAMS_NONINTERACTIVE=1 that auto-confirms teammate notifications without requiring stdin.

1. A webhook or file-based notification path for teammate status events, so an external orchestrator can observe completion without the lead needing to relay it.

1. The ability to inject messages via a named pipe or socket rather than stdin directly -- this would let a daemon-style orchestrator send the confirmation without the session being attached to a terminal.

The use case (scheduled, unattended multi-agent jobs) is large enough that it is worth a dedicated non-interactive mode rather than requiring everyone to build an external orchestration layer.