Docker sandboxes

Sandboxed, and still on your bar.

Claude Code in a local Docker sandbox runs in a VM of its own, where the hooks on your Mac can’t reach it. Turn on one switch and Evlat sets up each sandbox itself: its sessions sit on the bar beside your others, tagged with the sandbox’s name. You keep using sbx as you do.

Tagged by sandbox

Every session carries its sandbox’s name, the way a server’s rows carry the server’s. One that waits on you pulses amber like any other, and the face on the bar goes with it.

Back to its terminal

Go to session opens the terminal you ran its sbx run in, on its tab where that terminal allows it. Each sbx run is a session of its own, and Evlat tells them apart by when they started.

You answer in the sandbox

Answering from the bar and usage limits aren’t offered for sandbox sessions. The card shows what it waits on; you answer in its terminal.

Settings → Docker sandboxes · local sbx · Claude Code

One switch

Off until you turn it on.

You turn it on in Settings → Docker sandboxes, and the Claude Code card in Settings → This Mac points to it when sbx is on your Mac. Sandboxes running now are set up at once, new ones as they start. Nothing restarts: a session already running shows from its next message.

Settings lists every sandbox on your Mac with one state each. One that couldn’t be set up says why, with Try Again beside it.

Claude Code sessions running in a Docker sandbox on this Mac can show on the bar like any other session. Keep using sbx as you do: Evlat sets up each sandbox itself.

Watching

Watch sandboxesSandboxes running now are set up at once, new ones as they start. Nothing restarts: a session that is already running shows from its next message.

Watching. Sandboxes reach Evlat on port 48152.

Sandboxes on this Mac

claude-apiclaude · ~/Projects/api

Ready

claude-webclaude · ~/Projects/web

Ready

claude-docsclaude · ~/Projects/docs

Set up when it starts

What it does while on

Inside each Claude Code sandbox, as root, Evlat writes one file of its own: /etc/claude-code/managed-settings.d/evlat.json.
It lets that sandbox reach port 48152 on this Mac, and nothing else.
No file of yours on this Mac is touched. sbx keeps each sandbox’s rule on this Mac, and deletes it with the sandbox.
Turned off, both come out of the running sandboxes. A stopped sandbox keeps them: while Evlat isn’t listening, its hooks fail at once and Claude Code carries on.
Sandboxes in Docker’s cloud can’t reach this Mac.

Exactly what it changes

Inside each sandbox: One file of Evlat’s own, written as root: /etc/claude-code/managed-settings.d/evlat.json. Its hooks tell Evlat what Claude Code is doing. Your own ~/.claude in the sandbox is left as it is.
Between the two: One network rule for that sandbox alone: it may reach port 48152 on your Mac, and nothing else. sbx keeps the rule and deletes it with the sandbox.
On your Mac: No file of yours. Evlat listens on 127.0.0.1:48152 while the switch is on, for sandbox hooks only: a script’s rows still go to Evlat’s socket.

Good to know

Turning it off: The file and the rule come out of every running sandbox. A stopped one keeps them; while Evlat isn’t listening its hooks fail at once and Claude Code carries on. Evlat never starts a stopped sandbox to clean it.
Other agents: Only Claude Code sandboxes are set up for now. A sandbox running another agent is listed in Settings and left alone.
Docker’s cloud: Sandboxes in Docker’s cloud can’t reach your Mac, so only local ones show.
Another port: If another program holds 48152, Settings says so. EVLAT_SANDBOX_PORT picks another; see Limits & environment.

Download for Mac The reference in the docs