Running Claude Code in multiple terminal tabs
Two agent CLIs in two terminal tabs works. You can hold both in your head, you know which one you started last, and when one stops to ask a question you notice, because you are looking at it. Nothing about that arrangement is broken, and this page is not an argument that it is.
The trouble starts somewhere around the fourth tab. Not because terminals are the wrong place to run an agent — DeckSpace runs agents in terminals too. The problem is that a tab strip carries almost no state. It tells you a tab exists. It does not tell you which one is blocked on a permission prompt, which one has already written to your working tree, or what the one you closed an hour ago actually did.
This is a scale problem, not a criticism of the terminal. Below is what breaks at that scale, what a workspace gives you instead, and, at the end, the places where a workspace does nothing for you either. Every claim here is drawn from the DeckSpace documentation.
What actually goes wrong at four tabs
Four failures stack up, and they compound rather than queue.
- You cannot see which tab is waiting on you. An agent stopped at its own permission prompt looks the same as one that is thinking, and you cannot always switch the prompt off: Aider, Cursor Agent, Droid, Copilot CLI and Amp publish no unattended-mode flag at all, so those keep stopping to ask.
- You cannot see what each one has already changed. Several agents in one checkout write over each other's half-finished work, and you find out at commit time.
- Scrollback is the only record. It is not searchable across tabs, it is capped by your terminal, and closing the tab takes it with you. A run you want to explain tomorrow is gone.
- Nothing sits between the agent and your branch. The work lands, and then you read it.
None of these are terminal problems. They are the absence of a layer above the terminal.
What a workspace gives you instead
A DeckSpace workspace is a name and a folder. Panes belong to the workspace rather than to the app, so switching workspaces swaps the whole set of terminals at once. Each grid stays mounted while hidden, and its shells and running agents survive the switch.
One workspace holds up to 16 panes. Two split buttons in each pane header add one at a time: split right puts a new column beside it, split down stacks one below it inside the same column. Both go disabled once the workspace holds 16.
The cap does not silently drop work, and each launcher handles it differently. Launching into a new pane falls back to the active pane. The orchestrator logs that the pane limit is reached and waits for a task to finish. Team and Voice both error and say the grid is full.
Layout is saved per workspace — panes, working directories and theme — so a workspace reopens as you left it. Claude and Codex conversations resume automatically once their terminals are ready, using the saved and confirmed conversation ID. That restoration is deliberately inert: it does not resend your previous task or submit an unfinished prompt. Turn it off under Settings, AI, Restore conversations after restart.
Closing a pane kills its shell and any agent in it. Closing the last pane does not empty the workspace; it replaces the dead shell with one fresh pane.
Seeing what every agent is working on
Work moves through four columns — todo, in_progress, in_review and complete — and the desktop board renders those four. Cards live in the app's SQLite database alongside swarm messages and background jobs, so they survive a restart.
The board needs no macOS permission. Nothing is requested at install time, and panes, agents, the board and the review gate need none of it. Each permission is asked for the first time you use the feature that wants it: the microphone for dictation and the voice assistant, screen recording for the screenshot tool, automation for voice actions that drive other apps, accessibility and input monitoring for global hotkeys, and files and folders only if you run the optional filing-system scan.
Over the phone remote the board is read-only: you can read a card, you cannot move one.
Where the record of a run lives after you close the tab
Scheduled and background work is recorded rather than narrated. Run history shows the most recent 200 saved executions with their status, output and worktree branch. For a git project each execution creates its own worktree and branch, and if that worktree cannot be created or its identity cannot be saved, the agent does not start at all.
The rules that make the record usable are the honest ones:
- An interrupted execution is recorded as interrupted, not presented as a success.
- A job with no historical execution records is not given invented history.
- Each execution has a 30-minute wall-clock limit, and long output is bounded and marked where it was truncated.
- The scheduler allows at most two concurrent background jobs across the app.
Memory notes are plain markdown files in your repo, so you can grep, diff and commit them like any other file.
Reviewing an agent's diff before it reaches your branch
Agents do not share a checkout. Swarm splits a goal into tasks, and each task gets its own branch, its own git worktree and its own terminal pane, so your own checkout is not touched until you merge something into it. That is the answer to the second failure above: two agents cannot overwrite each other's half-finished work when neither is writing in your tree.
This is the piece a tab strip has no answer for: work done in a worktree can be reviewed before it reaches your branch. The gate is available, not compulsory — Merge is its own button, and you can take a worktree to your branch without running Review at all.
On a swarm task card, Review commits the worktree, predicts the merge, runs your project's checks, then has a reviewer agent return APPROVED or CHANGES_REQUESTED. None of that touches your branch, because the commit is in the worktree on its own branch. The merge is predicted with git merge-tree --write-tree against your current HEAD without mutating anything, and the conflicting paths are listed on the card.
A predicted conflict or a failed verification downgrades a clean approval to changes requested, and the Merge button relabels itself Merge anyway. Merging without a current clean approval — including when you never ran Review — takes two clicks: the first arms the button and warns you, and the second has to land within six seconds or the button disarms itself. The conflicting paths are listed on the card, so you can read them before the second click. Before a merge runs, a checkpoint commit of your working tree is written, and you can restore it from the Review room.
Team holds its own workers to the same standard. The reviewer runs with a 600-second limit, the verdict must contain a line that is exactly APPROVED or CHANGES_REQUESTED, and a timeout, a failed process exit or a missing verdict never counts as approval. A diff over 60,000 bytes stops automatic approval; split the task or merge it by hand.
All of this shells out to the system git, so git has to be installed.
Where a workspace does nothing for you
- A toggle is a flag lookup, not a feature. DeckSpace appends the flag your CLI publishes. Where the CLI has no such flag, the toggle is a silent no-op, and nothing in the pane tells you: set Fast Mode, launch Aider, and the toggle stays lit while the launch is unchanged.
- The write fence does not cover every pane. It wraps a pane only when the agent CLI is spawned as the pane's own process. A terminal pane you opened and typed into yourself is deliberately left alone, and the setup wizard's first panes are not fenced either, because the wizard launches by typing a command into a shell that is already running. Where the operating system has no sandbox available, the pane still opens and the fence is absent.
- One prompt across several panes can quietly collapse into the same prompt. If you give the setup wizard a first prompt and more than one terminal, it asks your CLI to split the goal into one subtask per pane. Any failure falls back to filling every pane with your original text, with no error and no toast. Write per-pane instructions yourself when you need distinct work.
- Panes die with the app. Reopening the Swarm room adopts the previous run rather than restarting it: the plan, branches and worktrees come back, and nothing is spawned.
- A builder pane's working directory is a temp path, not your project root. Worktrees sit under the operating system's temp directory, and macOS reaps that directory after a few days, so those tasks get a worktree-missing chip and lose their Review, PR and Merge buttons.
When a pile of tabs is still the right answer
One agent in one repo while you sit at the desk needs no board, no run history and no review gate. You are the board. Two agents is much the same. Open the tabs.
The case for a workspace starts at the point where you can no longer answer, without looking, which agent is blocked and what each one has already touched. That is usually somewhere past four.
DeckSpace ships no model and installs no agent CLI. It resolves the command on your login-shell PATH and runs it, so your existing auth, config and subscriptions come along. It is your CLI running, in a pane instead of a tab.
Try it on your own repo
DeckSpace is $24 a month or $228 a year, with a 7-day free trial. The trial is card-gated: there is no free tier and no unlicensed grace period in the app. It ships no model and installs no agent CLI, so it runs the ones already on your PATH, in panes instead of tabs.
Start the 7-day trialCommon questions
How many agents can I run in one DeckSpace workspace?
Up to 16 panes per workspace, and each pane can hold an agent CLI. The split buttons in each pane header go disabled once the workspace holds 16. The cap never silently drops work: launching into a new pane falls back to the active pane, the orchestrator logs that the pane limit is reached and waits for a task to finish, and Team and Voice both error and say the grid is full.
Do my existing CLI logins and settings carry over?
Yes. DeckSpace ships no model and installs no agent CLI. It resolves the command on your login-shell PATH and launches it, so your existing auth, config and subscriptions come along, because it is your own CLI running. If a CLI works in your terminal but the app cannot find it, register it as a custom agent with its absolute path, which is checked directly rather than searched for on PATH.
Can I tell which panes are safe to leave running unattended?
Partly. DeckSpace runs the agents it starts inside a write fence — a sandbox profile enforced by the kernel that denies file writes everywhere except the directory being worked in, the agent's own config and cache directories, and temp. Each pane records whether it is confined and by what, so a fenced pane can be told apart from an unfenced one. Two gaps are worth knowing. A terminal pane you opened and typed into yourself is deliberately never fenced. And the unattended-mode flag DeckSpace passes at launch does nothing for Aider, Cursor Agent, Droid, Copilot CLI or Amp, which publish no such flag, so those panes wait at their own permission prompt however you set the toggle.
What happens to running agents when I quit the app?
Panes and their processes die with the app. Reopening the Swarm room adopts the previous run rather than restarting it: the plan, branches and worktrees come back, and nothing is spawned. Background jobs run in the scheduler thread only while the app is open, so quitting stops them. tmux is the one optional exception, needed only for panes that survive quitting the app and for remote panes over ssh.
Is a workspace overkill if I only run one or two agents?
Probably, yes. One agent in one repo while you are at the desk needs no board, no run history and no review gate. Terminal tabs are a perfectly good answer at that scale. The case for a workspace starts when you can no longer say, without looking, which agent is blocked and what each one has already changed.