Sandboxing Claude Code for a team

Your developers already run Claude Code, each on their own machine, each with their own settings. Before its agents work on your tickets, the question is what they can touch. This page says what Claude Code's sandbox does, what it leaves to each developer, and what Tillerly sets for every session.

What the sandbox does

Claude Code's sandbox confines the shell commands an agent runs, and the processes they start, at the level of the operating system. On macOS it uses Seatbelt, built into the system. On Linux and WSL2 it uses bubblewrap. On Windows without WSL2, commands run with no sandbox.

Inside it, a command writes only to its working folder and the temporary folder, and reaches the network only through a proxy on the machine, which checks each host against the domains allowed.

What it leaves to each developer

  • It is off by default. A developer turns it on with /sandbox, or with sandbox.enabled in their settings. A company can require it of everyone through managed settings, deployed by its device management or from claude.ai.
  • It covers shell commands only. Claude's own file tools, Read, Edit and Write, follow permission rules instead, and so do its MCP servers. A file the sandbox hides from commands stays readable to the Read tool, unless a permission rule denies it too.
  • It reads the whole machine by default, credential files such as ~/.ssh and ~/.aws/credentials included, until a rule hides them.
  • A command can leave it. When a command fails in the sandbox, Claude may retry it outside, unless allowUnsandboxedCommands is false.
  • Without it, commands still run. When the sandbox cannot start, Claude Code runs commands with none, unless failIfUnavailable is true.

What Tillerly sets for every session

The Runner writes the same settings for every session of every member of your team. Nobody sets anything by hand.

  • Always on. enabled, failIfUnavailable and allowUnsandboxedCommands set to false. Without the sandbox the session does not start, and no command runs outside it.
  • Writes. Only the ticket's worktree, the temporary folder and the caches in your home. Never the Runner's data, your SSH keys, your git configuration or another ticket's worktree.
  • Reads. Everything but the Runner's data, your SSH keys, your git logins and the files your repository's git ignores. Every .env, .env.* and .envrc is hidden, but .env.example, from the commands and from the Read tool alike.
  • Network. Open, so that your checks can install and run, but never your code host, whose hosts are denied to every command.
  • Git. A session's git touches only its own branches, and cannot push. The Runner pushes the ticket's branch for it, and only that branch, never by force.
  • Credentials. The credentials a run's tools need are in the run's folder, readable only by you, and the folder is removed when the run ends.
  • The planner's git writes nothing and reaches no host.

What still leaves the machine

  • The agent sends what it reads to the model, through each member's own Claude Code login.
  • Its commands reach the network, to install and run your checks.
  • The service receives each run's log, what the agent said and the tools it called, and keeps it for the days your organization sets, 30 by default.

Where to go next

The page on security and data says what a session can do, and how organizations are kept apart. Getting started says what each member needs.