[FEATURE] Statusline: expose the currently viewed teammate/subagent's model and context in the JSON payload

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When running agent teams / subagents, selecting a teammate in the TUI (pressing Enter on it in the agents list) switches the main view to that agent's session — but a custom statusline keeps rendering the lead session's data. The model.display_name in the statusline JSON payload is always the lead's model, so the statusline reports the same model for every agent you view, regardless of what each agent was actually spawned with.

There is also no field in the statusline payload that identifies the currently viewed agent (no agent id, name, or per-agent transcript_path), so a statusline script has no way to look up the correct model itself — even though each agent's model is recorded in its transcript JSONL.

The statusline docs (https://code.claude.com/docs/en/statusline.md) list the refresh triggers (new assistant message, /compact, permission mode change, vim mode toggle, refreshInterval), and switching the viewed agent is not among them, so this appears to be a gap rather than a bug in my script.

Related prior issues:

• #27144 — statusline model.id reflected global state rather than per-session state (closed). Same underlying theme: the statusline model field not matching what the user is actually looking at.
• v2.1.199 changelog addressed an adjacent confusion (running /model while viewing a teammate now shows a notice that it applies to the lead), which suggests the "what am I looking at vs. what does the UI report" distinction in the teammate view is a known rough edge.

Proposed Solution

When the user switches the TUI to view a teammate/subagent, re-invoke the statusline command with that agent's context. Concretely, either (or both):

1. Populate the existing fields (model, context_window, transcript_path, session_id) from the viewed agent's session while it is being viewed, reverting to the lead's data when the user returns to the main conversation; or
2. Add a viewed_agent object to the payload, e.g.:

"viewed_agent": {
  "name": "plan-review",
  "id": "a1b2c3...",
  "model": { "id": "claude-opus-4-8", "display_name": "Opus 4.8" },
  "transcript_path": "/path/to/agent-transcript.jsonl"
}

Option 2 is likely safer for backward compatibility — existing statusline scripts keep working unchanged, and scripts that care about the teammate view can opt in.

Adding "viewed agent changed" to the statusline refresh triggers would be part of either variant.

Alternative Solutions

• Parsing the session's agent transcript JSONLs from the statusline script to find agent models works for logging purposes, but there is no reliable way to know which agent is currently being viewed when several run concurrently, so the script would guess wrong often.
• Displaying nothing model-related while agents are running avoids showing wrong data but loses useful information.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. Main session runs on one model; I spawn subagents with explicit model overrides (e.g. an adversarial reviewer on Opus, research sweeps on Sonnet).
2. I press Enter on a running teammate to watch its progress.
3. The statusline still shows the lead's model, so I can't confirm at a glance that the reviewer is actually on the model I intended — which matters both for quality expectations and for tracking Opus vs. Sonnet usage against rate limits.
4. With this feature, the statusline could render the viewed agent's real model (and ideally its own context-window usage), making per-agent model routing verifiable from the UI.

Additional Context

• Observed on v2.1.209, macOS, custom statusLine command configured in settings.json.
• Per-agent context-window data in the same payload would pair naturally with this, since an agent's context usage is independent of the lead's.