[FEATURE] VSCode extension: per-agent transcript separation — default to root-agent messages, switch into any subagent's context, and attribute every tool call to its agent
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
In the VSCode extension, every message in a session flows into one single stream: root-agent text, subagent text, tool calls and tool results from all of them, interleaved in one window. There is no agent identity anywhere in the view.
The moment more than one agent is running, I can't read the session:
- I can't tell which message came from the main session and which came from a subagent — or from which subagent.
- When a subagent reports something wrong, I can't scroll back to its context. I only have the merged soup, where its messages are split apart by three other agents' output.
- Tool calls carry no agent attribution at all. A
Bashor anEditin the stream can't be traced back to the agent that issued it, so I can't answer "who ran this?" or "what did the reviewer actually look at?". This part is missing in the Desktop app too, not only VSCode.
This is the normal shape of my sessions, not an edge case: I run several subagents in parallel (review lenses, refuters, verifiers, a bug worker) on every slice of work. The result is that the main session is drowned in output that isn't mine to read right now, while the output I do want later is unattributed and unrecoverable.
The Desktop app already separates agents, so the concept exists — the VSCode extension just doesn't have it.
Proposed Solution
1. Agent-scoped views in VSCode (parity with the Desktop app)
- A list of the agents in the session — root plus every subagent, live and finished — with name, subagent type, model, status and elapsed time.
- Clicking an agent switches the window into that agent's context: only its messages, its tool calls, its final result.
- The default view shows only the root agent's messages. Each subagent is collapsed to a single row (name, model, status, elapsed, one-line "current activity"), expanded only when I choose to look.
- A clear way back to the root transcript, and no loss of scroll position when switching.
**2. Tool calls grouped by agent, in the background-tasks panel (VSCode and Desktop)**
- Tool calls go to the background/tasks panel instead of inline in the main transcript.
- Every entry is labelled with the agent that issued it and is filterable by agent.
- From a subagent's row I can see exactly the tool calls it made, in order, with their results.
Goal in one line: less noise in the main session — only significant messages — with everything else still available on demand, always linked to the subagent that triggered it.
Alternative Solutions
- Reading the raw session JSONL — the attribution exists in the transcript file, so I have grepped it to reconstruct who ran what. That works, but it means leaving the IDE and hand-parsing to answer a question the UI already has the data for.
- Terminal sessions instead of the IDE — the TUI is currently easier to follow with parallel agents than the VSCode extension, which is backwards for an IDE integration.
- Fewer parallel subagents — I have deliberately reduced fan-out just to keep the transcript readable. That trades away real throughput for legibility.
- Related existing requests that don't cover this:
- #73413 — VS Code transcript view modes (Summary/Normal/Verbose): verbosity of tool calls, no agent identity.
- #72848 — hide/collapse subagent tool activity: hides it; doesn't attribute it or let me open it.
- #92950 — persistent subagent inspector: the right idea, but requested for the TUI, not VSCode.
- #75863 — Background Tasks panel (mine): visibility into what is running; this issue is about separating and attributing what they say and do.
Priority
High - Significant impact on productivity
Feature Category
Developer tools/SDK
Use Case Example
Example scenario — one slice of work in my spec-driven build:
- The root session hands a capability slice to an implementer subagent, then fans out four reviewers in parallel (correctness, security, spec compliance, sibling hunt), plus a bug worker on an unrelated file.
- Today: six agents write into one window. Reviewer output is cut in half by the bug worker's
Bashruns; the implementer'sEditcalls sit between two other agents' messages. I scroll for a minute and still can't reconstruct who did what. - With this feature: I see only the root agent's messages plus six collapsed status rows. The security reviewer's row says "reading auth middleware, 40s". I keep reading the root thread.
- The security reviewer reports a finding I doubt. I click its row, land in its transcript, and see exactly the files it read and the greps it ran — I can tell in seconds that it never opened the caller, so the finding is wrong.
- I switch back to the root agent and continue, without having lost my place.
- This saves me the scroll-and-guess pass I currently do after every fan-out, and it's the difference between trusting a subagent's report and having to redo its work myself.
Additional Context
- The Desktop app already has agent switching; this is largely a parity request for the VSCode extension. Item 2 (tool-call attribution and per-agent filtering in the background-tasks panel) is new work on both clients.
- Existing bugs suggest the subagent-view plumbing already exists in some clients and needs hardening as well as porting: #90492 (navigating between subagent views is broken), #93386 (subagent-active indicator disappears when switching into the subagent's transcript), #76503 (returning from an agent view respawns in-flight subagents).
- A reasonable unification: one "transcript scope" control (which agent) alongside the verbosity control asked for in #73413 (how much) — the two are orthogonal and shouldn't be collapsed into a single setting.
- The attribution data already exists in the session JSONL, so this should be a presentation-layer change rather than a protocol change.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗