Configure Claude Code Permission Rules, Settings Scopes, and Sandboxing

Quick answer

Use deny for actions or data that must never be available, ask for high-risk or external side effects, and narrow allow rules for routine deterministic checks. Put team rules in project settings and personal exceptions in untracked local settings; use managed policy for non-overridable organization controls. Permissions govern tool approval, while the Bash sandbox provides operating-system-level filesystem and network containment. Use both. Anthropic's permissions guide and sandbox guide are authoritative.

Understand evaluation and scope

Permission outcomes are evaluated in the safety order documented by Claude Code: deny, then ask, then allow. A broad deny cannot be bypassed by a narrower allow. Rules can match a whole tool or a tool plus specifier, such as a command prefix, path, domain, MCP server/tool, or agent parameter.

Typical settings layers include managed policy, command-line/session settings, project-local settings, shared project settings, and user settings. Review exact precedence in the current documentation before relying on a conflict. Keep local convenience rules out of version control.

Start from a small policy

{
  "permissions": {
    "allow": [
      "Bash(pnpm test *)",
      "Bash(pnpm typecheck)",
      "Bash(git status *)",
      "WebFetch(domain:code.claude.com)"
    ],
    "ask": [
      "Bash(git commit *)",
      "mcp__github__create_*"
    ],
    "deny": [
      "Read(**/.env)",
      "Read(~/.ssh/**)",
      "Bash(git push *)",
      "Bash(* deploy *)"
    ]
  }
}

This is illustrative, not a universal copy-paste policy. Match the actual commands, tool canonical names, paths, and operating system. Test compound commands and wrappers; permission patterns are not a general-purpose shell security language.

Choose permission modes deliberately

• Manual/default: good for unfamiliar repositories or sensitive work.
• Accept edits: reduces prompts for local file changes while retaining command review.
• Plan: research without source edits.
• Auto: where available, uses background safety checks; organization policy may disable it.
• Don't ask/dontAsk: useful for unattended runs with a complete pre-approved allowlist.
• Bypass permissions: only in isolated disposable environments with independent controls.

Mode convenience never changes the user's accountability for external impact.

Add the sandbox for enforcement

Permission rules influence whether Claude Code authorizes a tool call. They cannot reliably constrain every file a subprocess opens or every network operation embedded inside an allowed command. Sandbox controls enforce filesystem and network boundaries at the process layer. Configure writable paths narrowly, restrict network destinations, and avoid mounting host secrets into an autonomous container.

Test the boundary with negative cases: reading .env, writing outside the project, contacting an unapproved domain, following a symlink to a denied location, and invoking a blocked action through a wrapper. A policy is not complete until bypass attempts fail.

Lab: least-privilege test agent

Create a disposable repo where Claude may read source, edit tests, and run one test command, but may not read secrets, install packages, access arbitrary network destinations, commit, or push. Demonstrate allowed and denied cases, inspect /permissions, then document why every allowed capability is necessary.

FAQ

Are CLAUDE.md warnings equivalent to deny rules?

No. Instructions shape intent; permission and sandbox controls enforce capabilities.

Can I safely allow bash * inside a container?

Only if the container itself has minimal mounts, credentials, privileges, and network access. A container is not automatically disposable or harmless.

Why did a compound command still prompt?

Claude Code checks subcommands and shell operators. Each relevant component must qualify under the policy.