statusLine always reports the main session, even when a subagent or teammate transcript is focused

What happens

The bottom-bar statusLine always renders the main session's state, even when the focused transcript in the TUI is a Task subagent or an agent-team teammate. Switching panes changes the transcript above the bar but nothing in the bar.

So in a subagent pane you see:

• model.display_name — the main loop model, not the subagent's resolved model. A Haiku subagent pane still reads Opus 5.
• context_window.* — the main thread's context, so the usage bar is the main session's, not the focused agent's.
• context_window.current_usage — the main thread's last assistant-turn usage. Anything derived from it (e.g. a cache-hit-rate segment: cache_read_input_tokens / (input + cache_creation + cache_read)) is frozen at the last main-loop turn while the subagent does all the work.
• effort, cost, exceeds_200k_tokens — likewise main-thread values.

rate_limits.five_hour / seven_day are account-scoped, so those are the one part that is legitimately the same in every pane.

Version: Claude Code 2.1.220, Windows 11 (win32).

Repro

1. Any statusLine command that echoes model.display_name and context_window.used_percentage.
2. Dispatch a subagent on a different model (e.g. Agent with model: "haiku"), or run with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 and open a teammate.
3. Focus the subagent/teammate transcript.
4. Bar still shows the main session's model and context.

What the shipped bundle shows

Reading the 2.1.220 bundle, this looks structural rather than a rendering bug:

• statusLineText is a single scalar on the one global app store — it sits in the same initializer as tasks, transcripts, taskDecorations, runningSubagents, agentNameRegistry, replTab, viewSelectionMode. There is one status-line string for the whole app, not one per pane.
• It has a single producer: the status-line hook takes { messagesRef, lastAssistantMessageId, tokenUsage, vimMode }, builds the stdin payload with messages: <main REPL message list>, mainLoopModel, cwd, then writes the command's stdout into statusLineText.
• context_window is derived from that main-thread message list (last assistant message's usage), and model from mainLoopModel.
• Focusing a pane only moves a selector over transcripts / replTab / viewSelectionMode. It does not remount or re-parameterize the status-line hook, and the payload has no notion of which pane is focused.
• The payload does carry agent.name, but that is the main thread's agent type (as set by --agent), not the focused subagent — so a script cannot even detect that a different pane is in view, let alone render for it.

Net effect: there is no field in the statusLine stdin schema that identifies the focused agent, so this is not fixable from the status-line script side.

What I'd like

Make the bottom bar pane-aware. Either of these would solve it:

1. Re-invoke statusLine with the focused agent's context when the focused pane is a subagent/teammate — i.e. model, context_window, effort, cost resolved for that agent, plus a field identifying it (agent name/type/session id), with the main session's values still reachable (e.g. under a main_session key) so a script can render both.
2. Or, minimally, add a focused_agent block to the existing payload ({ name, type, model: { id, display_name }, context_window, effort }, absent when the main transcript is focused) and let the script decide what to display.

Option 1 is what I'd expect as a user; option 2 is backward-compatible and enough to unblock.

Related

• #80560 — subagentStatusLine only covers Task subagents, not teammate or workflow rows. That issue is about the agent-panel rows; its "Related" section notes this bottom-bar gap in passing, but there is no standalone issue for it. subagentStatusLine does not address the bottom bar at all.
• #83131 — subagentStatusLine docs list name unconditionally.

Docs

https://code.claude.com/docs/en/statusline