[BUG] Subagent view renders the main session's model/effort/agent identity instead of the subagent's (header, thinking indicator, agent list)
Summary
When you drill into a spawned subagent's view, the UI chrome renders the main session's identity — model, reasoning effort, and agent definition — instead of the subagent's own resolved values. This shows up as three symptoms on three surfaces, but they share one root: a subagent's resolved runtime identity is never threaded into the chrome that renders while its view is focused.
Filing as one issue because the three existing reports below each treat a single surface, and fixing them independently would mean three patches over one missing piece of state.
Repro
- Run a main session on model A with effort X (e.g. Fable 5, low effort) using the default agent.
- Spawn a subagent that resolves to a different identity — different model, different effort, and a custom agent definition (e.g. Sonnet, medium effort, a custom agent from
.claude/agents/). - Open that subagent's view (
ctrl+o, or via the backgrounded-agent manage list).
Expected vs actual
| Surface | Expected | Actual |
|---|---|---|
| Thinking indicator, inside the subagent's view | The subagent's effort | The main session's effort |
| View header (scroll to top) | The subagent's model, effort, agent definition | The main session's — the header does not change at all |
| Spawned-agent list | Agent name + its model/effort | Agent name only |
What is and isn't already filed
- #76055 — [FEATURE] Show subagent model and config in subagent detail view. Covers the header/detail-view surface, framed as missing info.
- #76319 — [Bug] Subagent displays incorrect model version in panel. The panel showing a wrong model (a Fable 5 subagent displayed as Opus 4.8) — same root, different surface.
- #77367 — Show the model powering each subagent task in the task display and /tasks list. Covers model in the list, but not effort.
Not covered by any of the above:
- The thinking indicator renders the main session's effort level. This is a wrong-value bug, not absent info — the UI actively states an effort the subagent is not running at, which is worse than showing nothing because it reads as authoritative.
- Effort in the agent list. #77367 asks only for model.
Why it matters
Per-agent model: frontmatter, the model/effort parameters on the Agent tool, and the CLAUDE_CODE_SUBAGENT_MODEL floor all mean subagents routinely run on a different model and effort than the session that spawned them. That divergence is exactly when you drill into a subagent's view — to check it behaved as configured. Today the chrome answers that question with the main session's values, so the surface that should confirm the configuration instead silently contradicts it.
Proposed shape
Thread the subagent's resolved identity — agent definition name, resolved model (after any CLAUDE_CODE_SUBAGENT_MODEL floor or per-agent frontmatter is applied), and resolved reasoning effort — into the view state, and resolve all three surfaces from that one source:
- Thinking indicator reads the focused subagent's effort.
- Header reflects the focused subagent's model / effort / agent definition, and restores the main session's on return.
- List entries render
name (model, effort)— behind a setting if the default label needs to stay terse.
Acceptance criteria
- Opening a subagent view whose model/effort differ from the main session shows the subagent's values in the header.
- The thinking indicator shows the subagent's effort, never the main session's.
- The header shows the subagent's agent definition, not the session's.
- Returning to the main thread restores the main session's values.
- List entries show the resolved model and effort (or do so when the setting is enabled).
- Resolved values reflect runtime resolution, not frontmatter as written — i.e. an env-level model floor is visible as applied.
Environment
- Version: 2.1.210
- Platform: darwin
3 Comments
I've noticed this issue for a few versions now. Really annoying because it makes it impossible to tell if the subagents were actually spawned as you instructed (ie: "use sonnet for subagents), because they all just appear the same as the main agent (ie: fable).
Easiest workaround to confirm instruction following is asking it to verify that the transcripts actually show it used the desired model. This is not tenable though long term. Such a waste of tokens.
Also worth noting these are the same bug I think: #76343, #73572
Confirming this is still present in 2.1.241, and adding hard evidence for the "env-level model floor" acceptance criterion above (
CLAUDE_CODE_SUBAGENT_MODEL).Setup
settings.json:"CLAUDE_CODE_SUBAGENT_MODEL": "sonnet"Repro
Claude Code v2.1.241 / Fable 5 · Claude Max / <cwd>— i.e. the parent session's model, unchanged.Ground truth from the transcript file
242/242 recorded API calls in that subagent's transcript used
claude-sonnet-5(the env-floor value), while the banner never showed anything but the parent's Fable 5 label for the entire run.This matches the "Resolved values reflect runtime resolution, not frontmatter as written" acceptance criterion exactly — the banner component appears to just re-read the parent session's model/plan state rather than the subagent's own resolved model, regardless of which mechanism (env floor, per-agent frontmatter, or Task-tool param) set it.
Happy to attach the full transcript grep output if useful for triage.