Thread workspaces: tabs per pane and 2 × 2 grids for parallel sessions

[BarretoDiego]

The problem

T3 Code is good at running several agents, but the web/desktop workspace still makes the user switch the entire chat surface every time they inspect another thread. Two common workflows remain awkward:

• keep a long-running implementation visible while checking a review or a usage investigation;
• compare two threads side by side without opening another browser window.

Discussion #7341 proposes browser-style thread tabs, while #6746 proposes split views. I built a small model that combines both without turning the whole app into an IDE window manager.

What I built

The active chat area becomes a thread workspace. A layout button offers one pane, two or three columns, two or three rows, or a 2 × 2 grid.

Screenshots — layouts, tabs, and safe reduction

Four real threads running in one 2 × 2 workspace. Each pane retains its own header, conversation, composer, terminal toggle, and tab bar.

Single-pane baseline	Layout picker
The existing chat remains the default and becomes the first workspace pane.	Switch between one, two, or three columns/rows and a 2 × 2 grid.

Grid controls in context	Reduced to two columns
The layout control stays attached to the active pane.	Reducing four panes to two preserves every open thread by moving removed-pane targets into surviving tab bars.

The interaction model

1. Pick a layout.
2. A newly added empty pane becomes selected.
3. Choose a thread from the sidebar to open it there.
4. Choose another thread while that pane is active to add another tab.
5. Click any pane/tab to make it the active workspace target.
6. Drag a tab to reorder it in the same pane or move it into another existing pane, including an empty one.

This keeps the sidebar as the one thread navigator instead of adding a second project/thread picker inside every pane.

Ownership of adjacent surfaces

• Terminal drawer stays with its thread pane. A command running beside one conversation does not visually jump to another pane.
• Right panel remains shared. Browser, files, diff, PR, terminal, and agents follow the selected thread, matching the existing single-active-context model.
• Maximizing the right panel temporarily hides the grid. Restoring it returns to the same layout.
• The URL follows the selected thread. Deep links and browser navigation remain meaningful; the final canonical tab cannot be closed until another thread is available.
• Drafts are first-class targets. A draft tab promotes to its created thread instead of leaving a duplicate stale tab behind.

Reducing a layout is non-destructive

Changing from four panes to two, or from two to one, redistributes tabs into surviving panes and preserves the selected target. This is the important reverse path: adding panes without a safe way back would make layout changes a one-way door.

Persistence and scope

• The selected layout is browser-local and survives reloads.
• Open tabs are rebuilt from the routed thread after reload, so deleted/inaccessible threads are not restored as stale state.
• The feature targets web and desktop. Mobile keeps its existing single-thread navigation.
• Four panes is the deliberate ceiling; this is for parallel context, not arbitrary tiling.

Branch and verification

Working branch: feature/thread-grid-tabs

Key commits:

1. 641bbe194 — thread workspace store, tabs/panes, routes, and user documentation
2. 76c3d1177 — final workspace integration polish
3. 747d8128b — fix the Base UI menu grouping found during the integrated browser pass
4. 987467f47 — add sortable tabs within and across the existing workspace panes
5. f2f9d96d2 — consolidate the reviewed grid and drag-and-drop histories into the Discussion branch

Verification performed on the branch:

• 7 focused store tests covering layout growth/reduction, tab movement, close behavior, selected targets, and draft promotion;
• web TypeScript check;
• integrated browser pass with four real threads in a 2 × 2 grid;
• reduction to two columns with tabs preserved and the selected thread still active;
• layout menu reopened after the Base UI fix without an error boundary.

Performance notes

• The workspace keeps a small fixed maximum of four panes.
• One shared diff worker pool wraps the workspace instead of creating a pool per chat.
• The right panel remains singular rather than multiplying expensive browser/diff/agent surfaces.
• There is no animation loop or websocket protocol change.

What I deliberately did not add

• No arbitrary drag-to-tile system.
• No persisted cross-reload tab session yet.
• No independent right panel per pane.
• No mobile split view.
• No changes to provider or orchestration contracts.

Would maintainers prefer tabs-only first, split panes first, or the combined model above? The implementation is already separated into a small browser-local store plus one workspace component, so I can cut it down without changing server contracts.