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

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When using Agent Teams in default mode (interactive TTY, not tmux), the lead session stops processing teammate responses after teammates finish their work. The teammate completes, goes idle ("Crunched for Xm"), and the lead remains stuck at "Idle · Waiting for results..." indefinitely.

The moment I click into the lead's terminal window and press any key (even without submitting), the teammate's response is immediately processed and the lead continues.

This happens consistently across sessions. In one test, a teammate sat in "Crunched" state for 30+ minutes before I manually clicked into the window and pressed a key to unstick the lead.

This is the lead-side counterpart to #34668 (which reports the teammate side stalling) and is likely caused by the same root issue identified in #26426: the InboxPoller is implemented as a React hook (setInterval inside the Ink TUI component tree) and only fires when the Ink render loop is active. When the lead is idle (no tool calls, no stdin events), the render loop throttles and inbox polling stalls.

What Should Happen?

The lead should process teammate responses immediately when they arrive, regardless of whether the user is actively interacting with the lead's terminal window.

Steps to Reproduce

1. Start Claude Code in default teammate mode (interactive TTY, no tmux)
2. Create a team and dispatch a teammate via TeamCreate + Task
3. Switch focus to a different terminal window/tab (do not interact with the lead's terminal)
4. Wait for the teammate to complete its work and go idle
5. Observe the lead remains at "Idle" / "Waiting for results..." for 5-30+ minutes
6. Click into the lead's terminal and press any key
7. The lead immediately processes the teammate's response and continues

Workarounds We Tested (None Worked)

| Approach | Result |
|----------|--------|
| iTerm2 anti-idle (ASCII 0 null byte every 60s) | ❌ No effect — null byte doesn't trigger Ink's keypress handler |
| SIGWINCH signal (pkill -SIGWINCH) to lead process | ❌ No effect — signal is delivered but doesn't wake inbox polling |
| Direct PTY write (echo -ne '\x1d' > /dev/ttysXXX) | ❌ No effect — byte reaches PTY but doesn't trigger Ink re-render |
| PostToolUse:SendMessage hook sending SIGWINCH | ❌ Hook may not fire (Task tool uses internal completion path, not SendMessage) |
| Manual keystroke in focused terminal | ✅ Only thing that works — immediate response |

Root Cause Analysis

The InboxPoller is a React hook using setInterval(1000ms) inside the Ink TUI (per #26426's analysis). When the lead session is idle:

1. No stdin events → Ink's render loop enters low-frequency mode
2. setInterval callbacks are starved (timer coalescing + render loop throttling)
3. Teammate messages accumulate in inbox JSON files, unread
4. Manual keystroke → stdin event → Ink re-render → setInterval fires → messages delivered

Why signals and PTY writes don't work: The issue is not simply that the Node.js event loop is sleeping. If it were, SIGWINCH would wake it. The fact that signals are delivered but don't trigger inbox polling suggests the stall is specifically in Ink's rendering/timer scheduling layer, not the underlying event loop. Only a genuine stdin keypress event triggers Ink's full input processing pipeline, which re-activates the render cycle and associated timers.

Suggested Fix

Decouple InboxPoller from the React render loop. Run inbox polling as a standalone setInterval in the main Node.js event loop (not as a React hook), or use fs.watch on the inbox directory for push-based notification instead of timer-based polling.

Claude Model

Opus

Is this a regression?

Yes — this was not present ~4-6 weeks ago. Likely introduced when idle CPU consumption was optimized (addressing issues like #17148, #22131), which throttled the Ink render loop.

Claude Code Version

2.1.83

Platform

Anthropic API (Max)

Operating System

macOS (Darwin 24.6.0, Apple Silicon)

Terminal/Shell

iTerm2 / zsh

Additional Information

• iTerm2 has DisableAppNap = 1 and NSAppSleepDisabled = 1 — App Nap is not the cause
• macOS timer coalescing is enabled (kern.timer.coalescing_enabled = 1) which may compound the issue
• 18+ concurrent Claude Code sessions running in parallel
• Related issues: #34668 (teammate side), #26426 (non-interactive/SDK mode), #24246 (delayed idle status)