DeckSpace docsWhat walk-away actually does
It removes the agent’s permission prompts. It does not remove the fence around them — and on some machines there is no fence.
Walk-away is the autonomy preset that stops an agent asking you for permission. People reach for it so they can start something and leave the desk. It is worth knowing precisely what it removes, what it leaves in place, and the cases where it does nothing at all.
The three things it changes
Walk-away is a shortcut that writes three independent settings at once. It is not a mode the app enters — you can set the same three by hand, and if you do, the app calls it custom.
| Preset | Launch flag | Assistant tools | Confirm gate |
|---|---|---|---|
| Ask | plan | everything asks | confirm everything |
| Plan | plan | web allowed; file, shell, memory and board ask | confirm risky |
| Walk-away | walk-away | everything allowed | no confirmation |
What your CLI actually receives
DeckSpace does not implement autonomy itself. It passes the flag your agent CLI publishes for it, and the CLIs do not agree on whether that flag exists. Five of the eleven have no such flag, so for those, turning walk-away on changes nothing.
| Agent CLI | What walk-away sends it |
|---|---|
| Claude Code | --dangerously-skip-permissions |
| Codex | --dangerously-bypass-approvals-and-sandbox |
| Antigravity | --dangerously-skip-permissions |
| OpenCode | --auto |
| Grok CLI | --always-approve |
| Qwen Code | --yolo |
| Aider | nothing — no flag exists |
| Cursor Agent | nothing — no flag exists |
| Droid | nothing — no flag exists |
| Copilot CLI | nothing — no flag exists |
| Amp | nothing — no flag exists |
The pane will still sit at its own prompt waiting for you. That is the CLI's behaviour, not a DeckSpace setting you have missed. Use one of the top six for unattended work, or drive the CLI's own auto-approval through the arguments you register with it.
What still stops an agent — and where it does not
Walk-away removes the prompts. It does not remove the write fence, which is a separate thing and is on by default. But the fence does not cover every pane, and the difference matters more than the setting does.
When it applies, the profile allows reads, execution and network freely, denies all file writes, then re-allows writes in exactly three places: the directory being worked in, the agent’s own config and cache directories, and temp. An agent stopped by it is stopped by the kernel — whether it writes directly, shells out, uses an absolute path, or runs a script that does it.
| How the agent was started | Kernel write fence |
|---|---|
| You launched the agent into its own pane The CLI is the pane’s own process. | fenced |
| Work DeckSpace runs without a pane Maestro’s reviewer pass, missions, scheduled jobs. | fenced |
| Work DeckSpace starts for you in a pane Swarm builders, Maestro workers, Kanban runs, skills, context handoff, and Atlas starting an agent in the pane you are looking at. | fenced |
| A terminal pane you opened yourself A shell, with whatever you type into it. | not fenced |
The last row is a choice, not a gap. The fence exists to confine what an agent does on your behalf. A terminal you opened yourself is yours, and DeckSpace does not sit between you and it.
A swarm builder is fenced and works in its own git worktree, so a run that goes wrong is thrown away rather than unpicked. The two protect different things: the fence stops writes landing outside the working directory, the worktree makes the work inside it disposable.
You do not have to infer it from a global setting. Each pane records whether it is confined and by what, so a pane running unfenced — because the OS has no sandbox, or because it is your own shell — can be told apart from one that is.
Which platforms have a fence at all
| Platform | Sandbox | Status |
|---|---|---|
| macOS | sandbox-exec (Seatbelt) | built in nothing to install |
| Linux | bwrap (Bubblewrap) | supported only if bwrap is installed |
| Windows | restricted token | built in reported only once proven on your machine |
If the OS has no sandbox available, DeckSpace still opens the pane — it degrades rather than refusing to run. That is deliberate, but it means the protection above is simply absent, and an agent on walk-away can write anywhere you can.
Windows is stricter about what counts as available, and deliberately so: a restricted-token fence can be present and still defeated by a group policy, an EDR product, a filesystem without ACLs, or a domain configuration — on one machine and no other. So DeckSpace runs a planted violation and only reports a fence once it has watched that violation fail on your machine. A sandbox nobody has watched fail is not a sandbox.
Check which one you have in Settings → Autonomy. It names the sandbox in use, or tells you there is none.
On macOS and Linux there is a second, weaker mechanism underneath, armed on agent panes whether or not the fence is: a guard that intercepts the destructive shell commands people actually regret — rm -rf, force-push, reset --hard. It is not part of any preset, so walk-away does not switch it off.
Windows does not have that second layer. The write fence is the only thing between an agent and your files there, where on macOS and Linux it is one of two.
But it is not a boundary and should not be treated as one. It catches common mistakes by name; it cannot catch every route to the same outcome. The sandbox is the fence. The command guard is a seatbelt. On a Mac or Linux box with no sandbox available you have the seatbelt only; on Windows you have the fence only.
Per-agent permission levels
The preset is app-wide, but a single agent can be started at its own level rather than inheriting the global one. Four levels exist:
| Level | What the agent may do |
|---|---|
| Plan | Read-only. Plans and explains, changes nothing. |
| Ask | Asks before each action. The safest level that still does work. |
| Auto-edit | Edits files without asking; still asks before shell commands. |
| Full | Approves its own actions so it can run unattended. |
Today these levels are chosen by Atlas, when you ask it to start an agent — it picks a level to match the work rather than handing every pane the global default. There is no control in the pane itself, so if you launch an agent by hand it uses the app-wide preset. Set that in Settings → Autonomy.
Turning it on and off
- Settings → Autonomy — the preset, the per-category tool permissions, and the sandbox switch, with the current sandbox named.
- The autonomy chip in the status bar — flips between full and ask without opening settings.
- Per pane, at launch — the permission level for that pane only.
All three write the same underlying settings, so they can never disagree about what is currently true.
Before you actually walk away
- Commit or stash first. The sandbox confines writes to your workspace — which is precisely where your uncommitted work is.
- Check Settings → Autonomy names a sandbox. If it says there is none, you are running without the fence at all.
- Know which panes are fenced. An agent launched into its own pane is; a swarm builder and a shell you type into are not. See the table above.
- Check your CLI is one of the six. Otherwise the pane will simply wait at a prompt.
- Prefer a worktree for anything speculative. Swarm and worktrees gives each agent its own checkout, so a bad run is thrown away rather than unpicked.
- Set a spend cap. Unattended and unbounded are different decisions — see Routing and spend.