[FEATURE] Split-pane UI: separate conversation from tool output/working

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 VS Code extension, tool calls, code output, and verbose reasoning are rendered inline between user messages and assistant responses. A typical exchange:

User question (2 lines)
├── tool call: Bash (3 lines)
├── tool output (80 lines)
├── tool call: Read (2 lines)
├── file contents (120 lines)
├── tool call: Grep (2 lines)
├── grep results (30 lines)
├── analysis / reasoning (40 lines)
└── actual answer to the question (3 lines) ← now 250+ lines below the user's question
The user's previous message is scrolled far off-screen by the time the response arrives. Following a human conversation (question → answer → question → answer) requires constant scrolling past tool output that the user doesn't need to read in real time.

This gets worse in longer sessions — after 10-15 exchanges the chat becomes essentially unreadable as a conversation. The signal (human Q&A) is buried in noise (tool execution logs).

Proposed Solution

Split the chat panel into two panes:

Left pane (conversation) Right pane (working)
User message
Tool call: Bash → output
Tool call: Read → file contents
Tool call: Grep → results
Assistant response
User message
Tool call: Edit → diff
Assistant response

Left pane: only user messages and assistant text responses. Clean, readable, scrollable as a conversation.
Right pane: tool calls, tool output, code blocks, diffs, file contents. Available for reference but doesn't break conversational flow.
Right pane could auto-scroll to show current tool execution while left pane stays anchored to the conversation.
Clicking a tool reference in the left pane could scroll/highlight the corresponding output in the right pane.

Alternative Solutions

Collapsible tool output: helps slightly but still pushes content down and requires manual collapse
Summary mode: loses transparency — users want to be able to see tool output, just not inline
Shorter responses: helps at the margins but doesn't solve the structural problem — even a single file read can be 100+ lines

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

A developer is debugging a z-order bug in a WPF multi-monitor app. The conversation goes:

User: "The floating video window disappears behind the overlay when I click. It's a z-order problem."

Claude needs to investigate — reads 3 files, greps for Topmost, checks SetWindowPos calls, reads SecondaryOverlay.cs. That's 5 tool calls generating ~400 lines of output.

Claude: "Found it. All windows are Topmost, competing in the same z-band. SecondaryOverlay should be non-Topmost."

The user wants to respond — but their original message is now 400+ lines up. They scroll, re-read, scroll back down, and reply:

User: "Yes, fix it and bump the version."

Claude edits 4 files, runs verification greps, creates a zip. Another ~300 lines of tool output.

Claude: "Done. Zip is in Downloads."

Three exchanges. The user scrolled past 700+ lines of tool output to follow a conversation that was 6 sentences long.

With split-pane, the left side reads:

User: "The floating video window disappears behind the overlay..." Claude: "Found it. All windows are Topmost, competing in the same z-band..." User: "Yes, fix it and bump the version." Claude: "Done. Zip is in Downloads."

Clean. Readable. The 700 lines of tool work is in the right pane if they want to inspect it. The conversation thread — the actual human exchange — is never broken.

Additional Context

Users lose track of the conversation thread in any session longer than a few exchanges
Scrolling back to find "what did I ask / what did they answer" is constant friction
Tool output is important for transparency but doesn't need to interrupt the reading flow
Power users who run complex multi-step tasks are hit hardest — exactly the users who benefit most from Claude Code