[BUG] VSCode: background agent output streams into foreground chat, disrupting active conversation

Preflight

• [x] I have searched existing issues and this specific angle isn't reported
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Summary

In the VSCode extension, when Claude spawns subagents with run_in_background: true (or when fork mode is active and all agents become background-by-default), the agent's complete output — all tool calls, all intermediate text responses, all reasoning — streams directly into the main foreground chat window. This defeats the stated purpose of background execution.

Additionally, when multiple background agents run simultaneously, their outputs intermingle with each other AND with the actual conversation in the chat window, making it very difficult to follow any of them or the foreground conversation.

Environment

• Claude Code VSCode Extension: v2.1.159
• Platform: macOS (Darwin 24.6.0)
• Shell: bash
• Models affected: claude-opus-4-6 (1M context), claude-opus-4-8 (1M context)

Expected behavior

Background agents should run concurrently while the user can continue working in the foreground chat. Per the documentation:

"Background subagents run concurrently while you continue working." "The fork appears in a panel below your prompt and runs in the background while you keep working."

In the terminal/TUI, this is implemented as a separate panel below the prompt input. The user can keep reading and responding in the main chat while the agent works separately.

Actual behavior

In the VSCode extension, there is no equivalent of the terminal's "panel below the prompt." Instead:

1. ALL background agent output — tool call descriptions, intermediate text, every response turn — streams directly into the main foreground chat window, inline with the user's conversation.
2. Multiple simultaneous background agents intermingle their output with each other and with the actual conversation, creating an unreadable jumble.
3. The user cannot read previous messages while agents are running (the chat is being actively modified/scrolled by background agent output).
4. The background/foreground distinction is meaningless from the user's perspective — a background agent is experientially identical to a foreground agent in VSCode.

Distinction from #9512 and #11950

Those issues are about subagent verbosity (showing tool call details vs. summaries). Both were closed as "not planned." This issue is different: the background vs. foreground separation is entirely absent in VSCode. Even a perfectly-summarized background agent that only produced a one-line result would still write that result into the main chat mid-conversation, interrupting whatever the user was reading.

The verbosity is a secondary concern. The primary concern is that background agents have no separate display space in VSCode and therefore cannot be background in any meaningful sense.

Related issues

• #54595 — Fork mode silently removed run_in_background from tool schema, making all agents background-by-default. Under fork mode, this display issue affects every single agent spawn.
• #9512 — Subagent output control settings (closed as not planned) — general verbosity, different problem
• #11950 — VSCode: hide subagent internals (closed as not planned) — similar complaint but framed as verbosity
• #60095 — Background task chips persist as Running — related background agent UI issues

Suggested fix directions

1. Display background agent output in a collapsible section in the VSCode chat (collapsed by default, expandable for inspection)
2. Show only a chip/status indicator while the agent runs; reveal output on click/expand
3. Route background agent output to a dedicated VSCode panel (e.g., "Claude Agents" sidebar view) rather than the main chat
4. At minimum, visually separate background agent output from the foreground conversation so intermingled output from multiple agents + conversation is distinguishable
5. Revert to original behavior of simply logging all background agent output to a log file instead of the updated behavior of all agent output going to the log file AND directly into the chat window. While 1-4 are better options (really would be nice to have agent output captured & easily accessible), simply reverting to the prior behavior would result in background agents actually allowing the user to continue working instead of completely derailing work until all background agents complete.