[BUG] Collapsed/inactive subagent task panels throttle agent loop by ~5-10x

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 an agent or subagent task in the Tasks panel is collapsed or not the actively-focused panel, its tool-output stream slows dramatically. Manually clicking the running task element to expand/focus it triggers an immediate burst of queued tool calls and the agent visibly catches up. Verified consistently across dozens of runs over ~3 days.

Multi-step plans that should complete in minutes are taking hours unless the user manually expands each running subagent panel as work progresses. Net result: the Code UI is rate-limiting its own agents.

What Should Happen?

Subagent task throughput should be independent of which UI panel is currently expanded or focused. The agent loop should pump at full speed regardless of whether the user is actively viewing that subagent's output.

Error Messages/Logs

Steps to Reproduce

1. Start a Claude Code session with a multi-step plan that uses subagents (e.g. anything dispatching multiple task implementers in sequence via the Task tool).
2. Let the session run with the Tasks panel collapsed, or with focus on a different panel/section in the UI.
3. Observe wall-clock time-to-completion for the running subagent — significantly slower than expected.
4. Click the running task row in the Tasks panel to expand/focus it.
5. Observe: a visible burst of queued tool calls fires within seconds. Throughput jumps roughly 5-10x.

Reproduces reliably across dozens of runs over ~3 days. Same Code build, same hardware, same plans — the only difference is whether the user is actively viewing the running subagent's panel.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Desktop app (Windows installer) — CLI not installed, version not retrievable from PATH

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Inferred mechanism: the renderer skips painting collapsed/inactive panels (Chromium-style backgrounding at the React/component level). If the agent loop's tool-output writeback path is gated on UI ack of the previous chunk, the loop blocks until paint resumes. Clicking expands the panel, paint resumes, ack flows, queued chunks drain in a burst.

Workaround that works: external script using Windows UI Automation to fire Invoke on running task elements every ~2s without stealing mouse/focus. Restores full speed. Brittle to UI element-naming changes; shouldn't be required.

Suggested fix directions:

• Decouple the agent loop's continuation from UI render ack. Tool output should buffer and the loop should advance regardless of panel paint state.
• If render-coupled architecture is intentional, expose a setting to "always pump panels at full speed" (trades a bit of CPU for not stalling agents).
• Or: keep the running subagent's panel painted at low priority even when collapsed (no need for full UI fidelity, just enough to not stall the loop).