[FEATURE] Desktop: named split-view layouts with lockable cells
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet — closest are #86925 (make split view the default), #69993 (keyboard pane splitting; new sessions shouldn't clobber a pane), and #73679 (pane focus shortcut). None cover saving a layout or locking a pane's session.
- [x] This is a single feature request (not multiple features)
Problem Statement
The desktop app's split view is great for running sessions in parallel, but the arrangement is ephemeral and fragile:
- Layouts can't be saved. Every time I sit down I rebuild the same arrangement by hand — e.g. orchestrator session on the left, two worker sessions on the right. There's no way to name that arrangement and get back to it in one action.
- Any pane can be clobbered at any time. Clicking a session in the left sidebar replaces whatever pane it lands in. When one pane holds a long-running session I'm monitoring (a merge orchestrator, a build babysitter), one stray sidebar click navigates it away, and I have to hunt the session down again to restore it.
For anyone running a stable multi-session workflow, the split-view arrangement is the workspace — but the app treats it as throwaway per-click state.
Proposed Solution
Two pieces, one feature — persistent layouts with lockable cells:
Named layouts
- Save the current split-view arrangement (grid shape + which session occupies which cell) as a named layout — e.g. "Keystone fleet".
- A layout picker (menu + command palette) switches the whole window to a saved layout in one action.
- Selecting a layout restores each cell's session. Cells reference active sessions when they're running; if a cell's session isn't active, the cell renders empty with a one-click affordance to launch/resume that session in place (same project + working directory).
Lockable cells
- A per-cell "lock" toggle (pin icon in the pane header). A locked cell's session cannot be replaced by sidebar navigation — clicking a session in the left nav targets an unlocked cell (or opens a new split) instead of overwriting the locked one.
- Explicitly unlocking, or closing the pane, is the only way to change a locked cell.
- Lock state is saved as part of the layout.
Alternative Solutions
- #86925 (split view as the default open behavior) reduces the clicks to build an arrangement but doesn't persist one or protect it.
- #69993's "new sessions shouldn't replace an open pane" fixes one clobber path (Cmd-N) but not sidebar navigation, and has no persistence.
- Undocked/floating windows per session avoid clobbering but give up the single-window grid entirely and still don't restore as a set.
- Today's workaround is manual: re-open each session via
⋮→ Open in → Split view every time, and be careful where I click.
Priority
Medium - Would be very helpful
Feature Category
Other
Use Case Example
- I run a long-lived orchestrator session (merges/CI babysitting) plus 2–3 short-lived implementation sessions in one window.
- I save this as layout "Fleet": orchestrator locked in the left cell, two unlocked cells on the right.
- Next morning I pick "Fleet" from the layout menu — the orchestrator session reattaches in its cell; the worker cells come up empty with a launch button since those sessions ended overnight.
- During the day I click around the sidebar freely to rotate worker sessions through the right-hand cells. The locked orchestrator pane never gets navigated away, so I never lose sight of it.
Additional Context
Prior art: browser/IDE conventions map cleanly here — VS Code's editor-group locking (workbench.action.lockEditorGroup, which makes a group refuse to open new editors) and pinned browser tabs are exactly the "lock" semantics proposed; tmux session/window persistence (tmux-resurrect) and iTerm2 window arrangements are the "named layout" semantics. Related open requests this would compose with rather than duplicate: #86925, #69993, #73679.