Lock down Claude Code: permissions, sandbox and secrets

Why an agent needs limits

A chatbot can only suggest code. Claude Code can do things: open any file you can open, change code and run commands in your terminal. That is what makes it useful, and it is also why you set limits first.

There are three layers, and they work together:

• Permission modes: how much Claude may do without asking you.
• Permission rules: specific things Claude may always do, must ask about, or may never do.
• The sandbox: an operating-system fence around shell commands, so even an approved command cannot wander off.

Permission modes, from careful to hands-off

Press Shift + Tab to switch modes during a session. The main ones:

• Manual (default in settings): Claude reads freely but asks before each edit or command. Best for sensitive code or when you are learning.
• Accept edits (acceptEdits): file edits and simple file commands such as mkdir and mv go through; other commands still ask.
• Plan (plan): Claude researches and proposes a plan before changing anything.
• Auto (auto): instead of asking you, a separate classifier model reviews each action and blocks the ones it judges unsafe. Recent versions start terminal sessions in this mode.
• Don't ask (dontAsk): only pre-approved tools run and everything else is refused. Good for locked-down scripts and CI.
• Bypass permissions (bypassPermissions, or the --dangerously-skip-permissions flag): no checks at all. Only use it inside a throwaway container or virtual machine.

Deny rules: keep secrets out of reach

Permission rules live in .claude/settings.json. They come in three lists: allow, ask and deny. Deny rules block in every mode, including bypass permissions, so they are the place for anything Claude must never touch.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

• Read(...) deny rules stop Claude's file tools from reading those paths. A .claudeignore file does nothing, so put those entries here instead.
• A Bash(...) rule matches the command as it is written. To block network access whatever the command looks like, use the sandbox's network settings.
• Run /permissions to see and edit every rule, and check it regularly.

Better still, keep live secrets off the machine Claude works on. Use test keys and fake data for development, and keep production credentials somewhere Claude cannot reach.

Turn on the sandbox

The sandbox is off by default. Run /sandbox in a session to turn it on, or set sandbox.enabled to true in your settings. While it is on, every shell command Claude runs, and every process those commands start, stays inside the fence:

• Writes: only the project folder, a temporary folder and any folders you add.
• Network: no direct route out. Requests go through a checker that only lets through the domains you allow, and that list starts empty.
• Reads: most of the machine by default, including files such as ~/.ssh, so add denyRead entries for anything sensitive.

On a Mac it works out of the box. On Linux and WSL2 it needs two small tools, bubblewrap and socat, and the /sandbox panel tells you if they are missing.

Make it a team standard

• Commit the settings: put shared rules in .claude/settings.json in the repository, so everyone gets the same deny list.
• Managed settings: organisations can push settings that individuals cannot override, for example to turn off bypass permissions.
• Review before it ships: run /security-review on your changes, and keep human review for logins, payments and personal data.
• Watch usage: Claude Code can send usage metrics through OpenTelemetry to the monitoring tools you already use.

The best setup is the one your team uses every day. Start with Manual or Accept edits, a deny list for secrets and the sandbox on, then relax things as you learn where the real risks are.

Check yourself

Three quick questions to check it stuck.

Ask the tutor

Frequently asked