Agent Teams: lead session stops processing teammate responses until manual keystroke (interactive TTY, default mode)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/34668
2. https://github.com/anthropics/claude-code/issues/36418
3. https://github.com/anthropics/claude-code/issues/26426

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

This has become a nightmare for us. Please help!! @bcherny

i see this also, on Windows, along with general agent-teams stop sending updates to team-lead.

Stable reproduces for us on long enough CC agent teams sessions

I see this on macOS. Claude Code has become unusable @bcherny

Confirming on Linux (WSL2) — same behavior as described.

Additional observation: The lead unsticks not only on a keystroke, but specifically on arrow-down + highlight (selecting any agent in the list without pressing Enter). This suggests the wake trigger is the TUI selection/focus change event in the agent picker, not necessarily a raw stdin keypress. This may narrow the root cause from "any Ink input event" to specifically the agent-list component's onHighlightItem or equivalent selection handler re-triggering the render cycle.

Environment:

• Claude Code v2.1.100
• Linux 6.6.87.2-microsoft-standard-WSL2
• Anthropic API (Max)
• bash / Windows Terminal

Workaround: PreToolUse hook that forces TaskList polling

We found a reliable workaround using the hook system. The root cause appears to be the Ink render loop stalling when the lead goes idle — no re-render means queued teammate SendMessage deliveries never flush to the UI.

The fix: a PreToolUse:TeamCreate hook that injects an additionalContext instruction telling the lead to poll TaskList every 30 seconds. This keeps the render loop active and messages flow without the arrow-key trick.

Hook script (team_lead_anti_idle.py):

#!/usr/bin/env python3
"""PreToolUse hook: inject anti-idle instruction when a team is created."""
import json
import sys

ANTI_IDLE = (
    "IMPORTANT: While waiting for teammates to complete work and send results via SendMessage, "
    "you MUST run TaskList every 30 seconds to check progress. Do NOT go idle between checks. "
    "This prevents a known UI rendering bug where teammate messages are not delivered until you interact."
)

def main():
    event = json.loads(sys.stdin.read())
    if event.get("tool_name") != "TeamCreate":
        sys.exit(0)

    print(json.dumps({
        "hookSpecificOutput": {
            "hookEventName": "PreToolUse",
            "permissionDecision": "allow",
            "permissionDecisionReason": "Anti-idle instruction for team lead",
            "additionalContext": ANTI_IDLE,
        }
    }))
    sys.exit(0)

if __name__ == "__main__":
    main()

settings.json entry:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "TeamCreate",
        "hooks": [
          {
            "type": "command",
            "command": "python3 '/path/to/team_lead_anti_idle.py'"
          }
        ]
      }
    ]
  }
}

Why it works: The TaskList tool calls force Ink to re-render, which processes the queued teammate message deliveries. The additionalContext field in the hook output gets injected as a system-reminder, so the lead treats it as a firm instruction rather than a suggestion.

Tested on: v2.1.100, Linux WSL2, Anthropic API (Max). Teammate messages delivered reliably across multiple team sessions without any manual keystrokes.

I noticed this around 2-3 weeks ago. Completely ruins my workflow plugin that orchestrates the Claude Agent Teams.

Screenshot of the bug in action while typing this comment. All "grey" team-agents in bottom status line are idle, messages are in the team-lead inbox. 👎

<img width="2299" height="773" alt="Image" src="https://github.com/user-attachments/assets/05bc9f92-85a4-4401-a086-d9b69f86ab59" />

Reproduced on Windows 11 with Windows Terminal + PowerShell at v2.1.113 — filed as #51167 (now closed as a duplicate of this) with full diagnostics before I found this issue. Same symptom: parent with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 dispatches teammates via TeamCreate + parallel Agent() calls, teammates complete cleanly, parent stays idle indefinitely until an input event hits the terminal. Your InboxPoller-on-Ink-render-hook analysis matches what I'm seeing from the Windows side; this isn't a macOS-only timer-coalescing or App-Nap problem.

Process-level evidence from the stalled parent, for what it's worth:

• CPU delta over a 5s sample while stalled: ~94ms (heartbeat only). A non-stalled parent actively working in the same state: ~720ms. Consistent with "event loop alive but callbacks starved," not hard-frozen.
• Thread wait reasons at stall time: 32 Unknown, 4 EventPairLow, 2 UserRequest across 38 threads.
• Ruled out Windows-specific red herrings: powercfg /powerthrottling disable on claude.exe (green-leaf confirmed absent), foreground/occlusion state, Windows Terminal "Always on top", software renderer, QuickEdit selection mode. None of them affect the repro.

One data point that may narrow the wake mechanism and that I don't see tested in the macOS reports: on Windows Terminal, giving the parent window focus alone wakes the parent — no click or keystroke required. Alt-Tabbing into the terminal from another app is sufficient. I haven't verified the mechanism; I suspect some focus-related byte (xterm focus reporting, mouse-tracking focus events, or a Windows Terminal side-channel) lands on stdin and traverses the same input pipeline a keystroke would, but that's a guess. Regardless of the exact path, the observation seems consistent with the InboxPoller hypothesis — it just means the set of "wake events" is broader than keystrokes. Most manual tests in the macOS reports seem to involve clicking into the terminal, which conflates focus change with mouse input; might be worth isolating.

If focus-alone-wakes holds up generally, there may be a cheap mitigation path that doesn't require restructuring InboxPoller off the React hook: on teammate report delivery, have the lead process nudge its own input pipeline somehow (a benign byte written to stdin, or whatever focus-in does internally). The input pipeline fires, Ink renders once, the starved setInterval gets serviced. Less clean than fs.watch or decoupling the poller from the render loop, but potentially a short-term unblock for wave-based multi-agent workflows without touching the TUI architecture.

The Windows process diagnostics on #51167 are still there if they're useful to whoever picks up the fix.

Reproduces on Linux (and inside tmux), Claude Code 2.1.150 — still live.

Hit this today on a long-running Agent Teams session. Same symptom as the OP: the lead is stuck at "Idle · Waiting for results…" while a finished teammate's message sits unprocessed in the inbox.

Environment

• Claude Code 2.1.150
• Debian 13 (trixie), Linux 6.12.75 aarch64 (Raspberry Pi 5)
• Agent Teams, in-process teammate mode (switchable agent views in one session, ← for agents — not tmux split-pane), interactive TTY hosted inside a tmux session. (OP noted "not tmux"; adding that it also reproduces when the interactive TTY itself is a tmux session, in-process mode — distinct from the split-pane case in #24108.)

On-disk evidence (single timezone)

• Lead's last turn (session transcript JSONL last write): 23:58:11
• Teammate completion → lead inbox (team-lead.json): "PR #140 re-pushed, ready to re-gate" + {"type":"idle_notification","idleReason":"available"}, written 00:08:17 — 10 min after the lead had already gone idle.
• 00:43 (35+ min later): lead still idle, zero new turns in its transcript; the message remains unread in the inbox file.
• A keystroke into the lead session drains and processes it immediately — matching the OP.

Observation:

Consistent with the OP and #26426: the InboxPoller setInterval lives inside the Ink render loop, which throttles when the lead is idle (no stdin/tool events), so delivered inbox messages aren't injected until input revives the loop. The inbox→lead-turn path stalls specifically in the idle state; #50779 covers the tool_use-chain deferral — same path, unreliable in both states.

Still live on the latest version (2.1.150). Happy to share raw inbox/transcript artifacts if useful.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.