The hub
The hub is where a worktree is actually worked on. Opening a row takes the main window over: a super-tab for each worktree you have open, and under it a strip of tabs for that worktree's sessions and surfaces.
The super-tab model
One super-tab per worktree, labelled by repo and worktree. Switching super-tabs switches the whole strip beneath it. The sessions belonging to the worktree you left keep running; they are only off screen.
Within a worktree, the tab strip mixes several kinds of tab:
| Tab | What it is |
|---|---|
| Claude, Codex, OpenCode | Agent sessions, one process each |
| Shell | A plain shell in the worktree's directory |
| VS Code | The editor, running as a web server for this folder |
| Browser | The preview browser, one tab per page |
| Knowledge Base | The worktree's own markdown files, browsable and rendered |
A tab's icon says what it is; its color says how it is doing — idle, working, or waiting on you. Tabs can be dragged into whatever order you want, and the order is remembered per worktree.
⌘+← and ⌘+→ walk the strip as a hold-and-release switcher with live previews of each tab, most recently used first.
Terminal tabs
Every terminal tab — agent or shell — is a PTY owned by a standalone daemon rather than by the window. That is the whole point: closing the tab, restarting the server, or updating the app leaves the process running, and the tab reattaches with its scrollback intact.
A worktree can hold more than one session of the same agent. The first is named after the agent, later ones are numbered: Claude, Claude 2, Claude 3.
For Codex and OpenCode the first session resumes that directory's last conversation and later ones start fresh, so two tabs never fight over one thread. Claude sessions are started plainly, with no resume flag of ours.
⌘+T opens another shell in the active worktree. ⌘+D splits the focused pane side by side and ⌘+⇧+D splits it top and bottom, so a shell can sit next to the agent that is editing the code.
The preview browser
A Browser tab is a real Chromium view of your dev server, with its own toolbar, multiple tabs per worktree, and DevTools you can dock to the bottom, dock to the right, or pop into a separate window. The divider between the page and the docked DevTools drags live.
This is also what agents see. The preview is exposed to agent sessions through a small MCP server, scoped so a session can only reach its own worktree's tabs — two agents in two worktrees each drive their own browser, never each other's.
Embedded VS Code
The VS Code tab runs the real editor as a web server, in an iframe that stays mounted when you switch away. VS Code's own keybindings work.
There is one shared editor server for the whole app, not one per worktree. The workbench is folder-agnostic and each tab opens its own worktree's folder against it, which is also why VS Code's browser-stored settings are the same in every tab.
Note
⌘+W is not close-window in the desktop shell — it closes the hub tab, and inside the VS Code tab it is handed to the editor untouched. Close Window lives on ⇧+⌘+W instead. ⌘+D is treated the same way: VS Code keeps it for add next match.
Embeds are desktop-only
The preview browser and the docked DevTools are Electron surfaces. They do not exist outside the desktop app, so a browser tab pointed at the local server gets terminals, diffs and the board, but no preview browser.
The VS Code tab has the same limit, for a different reason. Both tabs are
gated on one capability flag, and only the Electron shell turns it on for the
server it spawns. Against the standalone server you get from npm start, the
editor tab is absent too.
The app does not guess this. The server advertises what it can do, and the client hides the surfaces it cannot deliver rather than showing them greyed out. The same mechanism is why a worktree on a runner — a Linux box running Strado headless — shows no VS Code or Browser tab at all. See remote worktrees for the rest of what differs there.