Repository navigation
[Feature]:Split-view / pop-out support for viewing multiple chats simultaneously #3596
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I am describing a concrete problem or use case, not just a vague idea.
Area
apps/desktop
Problem or use case
When working with multiple threads (e.g. one for planning, one for implementation, one for debugging), I constantly have to switch back and forth between them in the sidebar. There's no way to see two chats side by side to compare outputs, track progress across conversations, or keep a reference thread visible while working in another.
Both the Claude desktop app and the Codex app support split-view (side-by-side) and/or pop-out windows for viewing multiple chats simultaneously. t3code is missing this entirely.
Proposed solution
Option A — Split view: A split-workspace mode where the main chat area can be divided into 2+ panes (side-by-side or stacked), each showing an independent thread. Users can open a thread in a new pane via a context menu action or keyboard shortcut.
Option B — Pop-out window: A "Pop out thread" button (or drag-to-detach) that opens a thread in a separate Electron/Browser window, allowing the OS window manager to handle the layout.
Ideally both, but either would be a meaningful improvement.
Why this matters
Multi-thread workflows are increasingly common (e.g. planning + coding + review, or coordinating across repos). Being able to view multiple threads at once reduces context-switching overhead, makes it easier to compare model outputs, and keeps reference conversations visible without losing your place.
Smallest useful scope
A single "split pane" action on a thread that opens it in a resizable pane to the right of the current chat, with a close button on the pane. No nesting, no kanban — just two threads side by side.
Alternatives considered
- Manually switching between threads via the sidebar (current behavior — works but loses context every time)
- Using separate app instances/windows (not practical — auth state, session management, and provider config don't sync)
- Third-party tiling WM (not applicable to most users, especially on macOS/Windows)
Risks or tradeoffs
- Adds complexity to the chat layout system
- Keyboard shortcut routing needs to be scoped to the active pane
- Thread state (e.g. streaming, pending tool calls) needs to work correctly when rendered in a non-primary pane
- Diff panel and file viewer may need to stay single-pane-only for v1
Examples or references
Contribution
- I would be open to helping implement this.
Activity
dthinkr commentedon Jul 31, 2026
Strong +1 from us. We regularly run several agent threads in parallel—for planning, implementation, and review—and the current sidebar-only switching adds a lot of context-switching overhead. A simple two-pane split view or “pop out thread” action would already make a meaningful difference; a full grid can come later.
ElliotDrel commentedon Aug 6, 2026
This existing request matches my workflow. One important requirement: split view should not be limited to passively viewing multiple chats. Each pane should remain fully interactive at the same time, so I can send messages, follow streaming output, handle approvals, and work across threads independently, including threads from different projects or environments. The active pane should be visually clear, but background panes should continue updating without being suspended.
gbretas commentedon Aug 9, 2026
been poking at this because I bounce between two threads all day and the sidebar round trip kills the flow.
good news:
ChatViewalready takesenvironmentId/threadIdas props and never touches the router, and the per-thread stores (rightPanelStore,terminalUiStateStore,composerDraftStore) are all keyed by threadKey already. so putting two of them side by side is more of a routing problem than a rewrite.the thing that actually breaks is
previewActionBus. it's a window broadcast, sopreview.togglewould fire in every mounted pane at once. terminal focus has the same problem. smallest fix I can see is putting the target threadKey on the event and letting panes ignore what isn't theirs.shape I'd try: extra panes live in search params (
/e1/thrA?panes=e2:thrB&focus=0), one pane is focused and that's whatuseHandleNewThreadand the global shortcuts resolve against, cap of 3, collapses to the focused pane when the window gets narrow. with one pane it renders the same tree it does today.is this something you'd actually want? I'm building it for myself either way, just not going to drop an XL PR nobody asked for.