[Feature]:Split-view / pop-out support for viewing multiple chats simultaneously

[nickmatteo]

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.

[dthinkr]

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]

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]

been poking at this because I bounce between two threads all day and the sidebar round trip kills the flow.

good news: ChatView already takes environmentId/threadId as 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, so preview.toggle would 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 what useHandleNewThread and 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.

[sniffle6]

100% agree. Split view is basically my most used feature.

[fredrik-sogaard]

+1 from me. I'm using the Claude Code extension in VS Code and regularly run 3-4 sessions side by side.

[olafura]

This gist is a demonstration of how this feature could be built or customized with the Qt/QML branch. It is an example to try and adapt, not a complete implementation of the discussion request or a feature shipped in upstream T3 Code.

Here's an opt-in Qt-shell split-view example with independently navigable panes, a resizable divider, Close right pane, and pop-out. Pairing is shared; each view has its own draft and panel state.

Open the second pane after the first finishes pairing. Pop-out creates another window without removing the pane. This example has two panes; it doesn't add drag-to-detach or restore the layout after restart.

Demonstration gist and setup.

Two panes on workspace 5 showing different demo threads and different unsent drafts. Pairing and server state remain shared.

Code and checks assisted by Codex.

[olafura]

Sorry for the lack of context this is showing how using this technique in the linked discussion would help with your issue #10708

[marceloconcli]

I've been working on a local fork with VS Code/Cursor-style chat splits: drag sessions around, resize them, and keep several interactive chats visible. It's off by default and enabled in settings.

My main use case is reviewing several PRs and getting them ready to merge. I might have two independent reviews running, a second opinion on one change, and another session fixing review findings or resolving a merge conflict in a separate worktree. Keeping those conversations visible makes it easier to compare findings and ask follow-up questions without constantly switching threads.

I read the decisions on #11434 and #2177, so I understand that an optional setting doesn't resolve the product and maintenance concerns.

Would a simpler, opt-in view with just two interactive chats side by side fit the direction? Fixed columns, no tabs, dragging, resizing, or saved layouts, and one focused chat on narrow screens. That would be a separate, smaller version of what's in the demo.

If there's interest, I'd like to coordinate with #10783 and #8149. Otherwise, happy to keep this in the fork.

The video uses sample conversations and scripted gestures. Targeted tests and web typecheck pass, but live-agent, physical drag, desktop, remote, accessibility, and performance testing are still outstanding. Built with GPT-6 in Codex.

session-workspace-full-demo.mp4

[marceloconcli]

@juliusmarminge, following your note on #10783, I shared a prototype demo above. It’s chat-only, with drag, resize, and tabs; the fixed two-chat version would be a smaller alternative. Would either scope be worth taking forward? Excited to contribute on that.

[0xCaso]

I built a working split view on a branch and would like to agree on scope with you before opening a PR, per the prior approval rule (and @juliusmarminge's note on #10783).

Full-resolution MP4 · all screenshots

What it does (web + desktop, client-only)

• Several threads in one window: up to 4 columns, 2 panes per column, 4 tabs per pane. Every pane is a full, live ChatView: you can send, stream, and answer approvals in all of them at once.
• The pane you last clicked is the active one: the route, sidebar highlight, terminal, right panel, and shortcuts follow it. Inactive panes fade slightly (opacity, no outline or animation).
• Ways in: a "New thread on the right" button next to the panel toggles (only in the single view), mod+\, the command palette, "Open in new column / new tab" in the thread context menu, middle-click for a new tab, and dragging a thread from the sidebar onto a pane (edges add a column or row, the tab bar adds a tab; dropping on the composer still adds the thread as context).
• Ways out: close a tab or pane (mod+shift+W). When the last split closes, you're back to the normal single view.
• A narrow window never squeezes columns below 400 px. It hides the rightmost columns, and a +N button brings them back.
• Desktop shortcuts: mod+T new tab, mod+alt+arrows move focus, mod+alt+1…8 jump to a pane. All are rebindable in Settings → Keybindings.

Screenshots

Three columns, a row, and tabs:

Dragging a sidebar thread onto a pane edge:

Narrow window, rightmost column hidden behind +1:

What it doesn't touch

• No server, orchestration, or wire changes beyond new keybinding command IDs in packages/contracts. The layout is client state in localStorage, so it works the same locally, remotely, and over T3 Connect.
• The single-thread view is unchanged until you split.
• Mobile: out of scope. Phones don't have the width, and the iPad layout would be its own discussion.
• Performance: panes reuse the existing per-thread stores; hidden ("parked") columns don't re-render on resize; no continuous animations.

Scope question

Which of these would you be open to reviewing?

1. As shown: columns + rows + tabs, drag and drop, shortcuts.
2. Smaller: columns only (side by side, no rows or tabs). The button, mod+\, the context menu, and drag to the edge stay.
3. Smallest: a fixed two-pane split.

I'm happy to cut it down to whichever you prefer and split it into a stack of focused PRs.

[LaNinja06]

+1 for this! I run multiple sessions/threads at once all day, and switching threads in the sidebar is the biggest friction I have in T3 Code.

I built a working version locally, just to check and see how it feels day to day. Check out the short demo:

split_view_t3.mp4

What it does:

• Open a sidebar thread beside or below the current one, resize the panes, and close a pane.
• Every pane stays fully interactive and keeps streaming.
• Keyboard shortcuts and global actions apply to the selected pane only.
• Narrow windows fall back to one thread. It is web and desktop only. Mobile is unchanged.

I know @marceloconcli and @0xCaso have also built versions, so I'm not asking you to take mine. I'd just be happy to see this feature land in some form, and I'm glad to help test or contribute to whichever version you choose. :)

[tharuxpert]

+1. I juggle several projects at once, and having to switch whole chats to check progress in each one is the main thing slowing me down. Even a plain fixed two-pane split with no tabs or dragging would cover my use case.

[Ziqi-Cui]

Adding a concrete parent/subagent use case, tested on T3 Code desktop v0.1.2 on Windows x64 with an Ubuntu WSL backend and Codex CLI 0.163.0.

I started a task in T3 that spawned two native Codex subagents. T3 correctly showed their status and let me open each child's own activity and final response. The remaining friction is navigation: opening a child replaces the main conversation view. I want to keep the parent visible while inspecting a child's progress, then inspect another child without repeatedly leaving and returning to the parent.

Workaround verified: keep the parent open in the desktop app and pair a browser client with the same WSL T3 server, using a read-only connection for the child view. Put the two windows side by side. Both views can show the existing parent and child independently, without starting another agent or another model run. This demonstrates the workflow is useful; it does not establish that native multi-pane support is trivial or that all live-streaming, focus, and reconnect cases are already solved.

A small first step that would cover this use case:

• Add Open beside parent to the subagent card/Agents/Lineage entry. Keep the parent conversation and composer visible, and show one selected child in a secondary read-only pane.
• Preserve independent scroll positions. Selecting another child updates the secondary pane; closing that pane only dismisses the view and does not stop or archive the child.
• Keep each pane's thread identity, model, status, and recent activity clear. On narrow screens, the existing single-view navigation can remain the fallback.

A full grid, tabs, drag and drop, and multiple interactive composers are not necessary for this first slice. Open subagent in new window would also be useful, with desktop multi-window support tracked separately in #6740.

If an upstream workflow already supports this in a newer build, a pointer to it would help. Otherwise, please consider parent/subagent inspection as an additional reason for the smallest two-pane version discussed here.

Posted with the user's authorization; drafted with Codex from a local test.

[mustafa-ramax]

Thats very useful to have mate!

[krishna-goutham-tls]

I came to T3 Code from the Claude desktop app. There, I drag a session from the sidebar into the chat area and it opens as a second pane, and both stay live. I keep 2-3 Claude Code sessions open like that. In T3 Code I go back to the sidebar every time I want to check on one.

Most comments here ask for the same thing: two or more interactive chats side by side, with no tabs or rows. Of the scopes offered so far, columns only with drag-to-edge (option 2 in the 0xCaso comment) fits that best. A fixed two-pane split would still be a big step up for me.