[FEATURE] Desktop: named split-view layouts with lockable cells

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 19, 2026

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:

  1. 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.
  2. 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

  1. I run a long-lived orchestrator session (merges/CI babysitting) plus 2–3 short-lived implementation sessions in one window.
  2. I save this as layout "Fleet": orchestrator locked in the left cell, two unlocked cells on the right.
  3. 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.
  4. 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.

View original on GitHub ↗