Taming the Permission Nag — Sandboxing Claude Code on macOS

So if you’ve used Claude Code for more than about five minutes you’ll have noticed that it really likes to ask for permission. Want to run a test? Permission. Want to write a file? Permission. Want to cat a log? You guessed it. After a while you end up just hammering “approve” like a cookie clicker game and at that point the whole security model is doing more harm than good because you’re not even reading what you’re approving anymore.

Anthropic themselves acknowledge this — they call it “approval fatigue” and by their own numbers, enabling sandboxing reduces those permission prompts by around 84%. That’s a big number, and having used it for a while now I can tell you it feels like even more than that.

What is sandboxing in Claude Code? #

Rather than asking you “can I do this?” every single time, sandboxing flips the model on its head. You define a set of boundaries up front — where Claude can read, where it can write, and what network hosts it can talk to — and then anything that falls inside those boundaries just happens without a prompt. If it tries to do something outside the sandbox, then you get notified and can decide what to do about it.

On macOS this works out of the box because it uses Apple’s built-in Seatbelt framework (sandbox-exec) which has been around for years and is the same technology that macOS uses to sandbox its own apps. No extra dependencies, no Docker, no VMs — just OS-level enforcement that applies not only to Claude’s direct commands but to every subprocess and script it spawns.

The sandbox enforces two types of isolation:

Filesystem — By default, Claude gets read and write access to your current working directory and read-only access to most of the rest of the system. It can’t go modifying your ~/.bashrc, touching your SSH keys, or writing to /usr/local/bin.

Network — All network traffic goes through a proxy running outside the sandbox. Only approved domains can be reached, and if Claude (or anything it runs) tries to phone home to somewhere unexpected, the request gets blocked and you get a prompt.

The combination of both is important. Without network isolation a compromised agent could read your files and exfiltrate them. Without filesystem isolation it could backdoor something to get network access later. You need both.

Getting started on macOS #

The good news is that on a Mac there’s genuinely nothing to install. Just open Claude Code in your project directory and run:

/sandbox

This gives you a menu with two modes:

Auto-allow mode — This is the one you probably want. Bash commands that can run safely inside the sandbox execute automatically without prompting. Anything that can’t be sandboxed (like a command that needs to reach a host that isn’t on the allowed list) falls back to the normal permission flow.

Regular permissions mode — The sandbox restrictions still apply but every command still goes through the normal approval process. Useful if you want the security boundary but don’t want to give up the control.

For most day-to-day development, auto-allow mode is the sweet spot — you get the flow of not being interrupted every 10 seconds whilst still having OS-level guardrails preventing anything dodgy from happening.

When you need to tweak things #

The defaults are fairly sensible but depending on your workflow you might need to open things up a bit. For example if your project uses kubectl or terraform they might need to write outside of the project directory.

You can grant write access to additional paths in your settings.json:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

Similarly, some tools just don’t play nicely with the sandbox at all. Docker is the obvious one — it needs host-level access that the sandbox restricts. You can exclude specific commands so they bypass the sandbox but still go through the normal permission flow:

{
  "sandbox": {
    "excludedCommands": ["docker *"]
  }
}

Worth noting that these exclusions don’t just silently let commands run — they fall back to the regular permissions system so you still get asked before anything potentially destructive happens.

If you want to go the other direction and lock things down further, you can restrict read access too. For example to deny reads from your entire home directory except the current project:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

The "." here resolves relative to wherever the settings file lives — so in a project .claude/settings.json it means the project root, which is probably what you want.

The safety net — source control #

So sandboxing handles the “Claude shouldn’t be able to mess with things outside my project” part of the equation. But what about inside the project? Claude has full write access to your working directory and in auto-allow mode it’s happily making changes without asking. What if it makes a mess?

This is where source control becomes your best friend. If you’re already using git (and if you’re using Claude Code for development then you almost certainly are) then you have a natural safety net:

Commit or stash before a big session — Before you let Claude loose on a chunk of work, make sure your current state is committed or at least stashed. That way if things go sideways you can just git checkout . or git stash pop and you’re back to where you started.

Use branches — If Claude is working on something substantial, do it on a branch. If the result is good, merge it. If not, delete the branch and move on. This costs you nothing and gives you a clean rollback path.

Review diffs before committing — Claude Code makes it easy to let the AI do the driving but you should still be reviewing git diff before you commit. The sandbox prevents damage outside the project; your eyes on the diff prevent damage inside it.

Small, frequent commits — The more granular your commits, the easier it is to cherry-pick the good bits and revert the bad. This is good practice regardless of whether an AI is involved.

Think of it this way: the sandbox is like the guardrails on a bowling lane — it keeps the ball on the lane. Source control is your ability to rewind the tape if you throw a gutter ball anyway.

A couple of other things worth knowing #

The escape hatch — Claude Code has a built-in mechanism where if a command fails because of sandbox restrictions, it can retry the command outside the sandbox but only with your explicit approval. This is handy when a legitimate tool genuinely needs broader access, but if you’d rather not have that option at all you can disable it:

{
  "sandbox": {
    "allowUnsandboxedCommands": false
  }
}

Hard failure mode — By default if the sandbox can’t start for whatever reason Claude Code will warn you but carry on without sandboxing. If you want to make absolutely sure that no command runs without a sandbox, set:

{
  "sandbox": {
    "failIfUnavailable": true
  }
}

Built-in file tools are separate — The sandbox only covers bash commands and their subprocesses. Claude’s own Read, Edit and Write tools go through the separate permissions system. So even with sandboxing enabled, if Claude uses its Edit tool to change a file you’ll still get prompted according to your normal permission settings.

Is it worth it? #

For me, absolutely. The difference in workflow is night and day. Before sandboxing I would either get bogged down in a constant stream of approve/deny prompts or I’d end up just auto-approving everything which kind of defeats the purpose of having security in the first place.

With sandboxing enabled, Claude can run tests, build projects, grep through logs, and generally do its job without me having to babysit every single command. And when it does try something outside the boundaries I get a clear notification and can make a considered decision rather than reflexively clicking approve for the hundredth time that session.

Combine that with sensible source control hygiene and you end up with a setup where Claude has enough freedom to be genuinely useful whilst you have enough safety nets to not worry about it going off the rails.

If you haven’t tried it yet, open Claude Code and type /sandbox. It takes about 5 seconds to enable and on macOS there’s literally nothing else to install. Give it a go — your approve button will thank you.