Claude Code Permissions and Sandboxing

Claude Code permissions determine whether a tool may run, whether it requires approval, and whether the application blocks it. Sandboxing restricts the files and network destinations available to a running process. They are separate controls: approving a command does not isolate it, and an isolated command can still damage files or use services that its environment permits.^[1][14]

Anthropic introduced its sandboxed Bash tool in October 2025 to reduce repeated approval prompts while limiting command access. The implementation uses operating-system controls rather than relying on the model to obey a written instruction.^[10] This reference describes the documentation reviewed on September 27, 2026, alongside the official changelog through Claude Code 2.1.283. Older clients can differ, especially in their starting permission mode.^[3][17]

Quick reference

For a broader command lookup, see Claude Code CLI Flags.

Permission modes

The modes are not equivalent security levels: dontAsk denies unapproved calls; bypass generally permits them.^[3]

From 2.1.283, interactive terminal and VS Code sessions start in auto mode when available and not overridden. The value named default therefore does not necessarily describe a session's starting mode.^[3][17]

Interactive terminal sessions with bypass available do not enforce Plan mode's usual edit restrictions. A planning prompt is therefore not a read-only boundary.^[3]

Auto mode and sandbox auto-allow

Auto mode delegates approval decisions to a classifier. Anthropic's March 2026 engineering account describes a separate prompt-injection probe on tool outputs and a classifier that evaluates proposed actions against user intent. The classifier can miss harmful actions or reject legitimate ones; its published evaluation is not a guarantee for a particular repository or task.^[11]

sandbox.autoAllowBashIfSandboxed approves sandboxed commands without the normal review flow. Turning it off preserves isolation. Content-specific ask rules still apply in auto-allow, but a blanket Bash ask rule is skipped.^[5]

Writing and understanding permission rules

Rules use a tool name, optionally followed by a specifier. Put them under permissions.allow, permissions.ask, or permissions.deny. Evaluation is deny first, then ask, then allow. A narrower allow rule cannot override a matching broad deny.^[2]

Rules do not recursively describe every action a program might perform. An allowed script can open files internally, and a command-name deny is not a general prohibition on the same effect through another program. For example, Anthropic documents that Bash(git push *) does not match git -C . push. Operating-system restrictions address a different problem from command-pattern matching.^[14][18]

Instructions in CLAUDE.md guide the model but do not change these access checks. Hook-based decisions can add application-level enforcement; they are not operating-system isolation.^[2][15]

What the sandbox contains

The integrated command sandbox covers Bash, PowerShell, and Monitor commands and their descendants. Built-in file tools, Model Context Protocol servers, and command hooks are outside that per-command boundary. Wrapping the whole Claude Code process in an appropriately configured runtime, container, or virtual machine covers a larger execution surface.^[1]

Integrated platform support is documented as follows:^[6]

The standalone @anthropic-ai/sandbox-runtime has Windows support, which does not establish support in Claude Code's integrated feature.^[7]

The runtime enforces restrictions across the process tree. Its Linux implementation uses namespace isolation and host-side proxies; macOS uses Seatbelt profiles and a controlled proxy connection. Thus a program launched by an approved shell command remains subject to the process boundary.^[7]

Files, credentials, and path syntax

Default writable locations include working, added, and per-user temporary directories. Reads can include credentials: enabling sandboxing does not automatically hide SSH keys or cloud credentials.^[6]

The runtime uses separate read and write policies. Write grants identify writable areas, with write denials taking precedence. Read rules can deny a broad area and reopen a narrower one; more specific denies still protect files within a broader reopened region.^[7]

Path syntax differs between configuration layers:

A single leading slash in Read/Edit rules is project-relative, unlike sandbox filesystem paths.^[2][6]

sandbox.credentials can deny files and strip environment variables. Separately configured masking substitutes placeholders and injects real credentials at the proxy, subject to platform and TLS requirements. Neither is automatically enabled by sandboxing.^[5]

Important settings and exceptions

The following settings control separate aspects of execution:^[5]

Enabling sandboxing does not imply fail-closed startup. Blocking retries does not remove explicitly excluded commands.^[6]

dangerouslyDisableSandbox requests an unsandboxed retry through ordinary permissions, potentially reviewed by a classifier rather than a human. Disabling retries does not contain the whole session.^[6]

excludedCommands merges across loaded settings sources without a managed-only lock. Exclusions remain possible with retries disabled; inspect resolved settings rather than assuming absolute containment.^[5]

The bypass flag

Claude --dangerously-skip-permissions selects bypassPermissions; it does not create an isolated environment. --allow-dangerously-skip-permissions makes the mode available without immediately selecting it. The similarly named dangerouslyDisableSandbox is a tool parameter, not the same control.^[8]

Anthropic recommends an outer isolation boundary for unattended bypass use. That boundary must account for file tools, hooks, and MCP processes as well as shell commands.^[1]

Settings scopes and precedence

The usual scalar precedence, highest first, is managed, command line, project-local, shared project, then user. Lists commonly merge instead of replacing one another, and some restrictive controls have special rules. An empty array is therefore not a reliable way to erase inherited permissions.^[4]

Administrators can distribute managed settings through device policy, files, or supported server-managed mechanisms. /status identifies the source; claude doctor reports rejected entries. A policy on a developer's computer does not automatically reach a separately hosted cloud environment.^[12]

Managed policy can disable bypass mode and limit permission rules to the managed tier with allowManagedPermissionRulesOnly. Such controls govern Claude Code's configuration. They do not remove a developer's independent operating-system access or prevent use of another program.^[12]

Conservative configuration example

This illustrative launch requests manual review and fail-closed sandbox startup without editing settings files:^[8][18]

claude --permission-mode default --settings '{"sandbox":{"enabled":true,"autoAllowBashIfSandboxed":false,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}'

Existing allow rules, exclusions, filesystem grants, and managed policy remain relevant. Review /permissions, /sandbox, and /status. This is neither a credential-isolation profile nor an offline environment.^[4]

Anthropic's secure-deployment guidance recommends narrowly scoped, preferably read-only mounts, controlled network endpoints, and proxy-held credentials. These controls must fit the workload.^[14]

Security limits and operational review

A writable project remains writable inside a sandbox. In a development container, the bind-mounted workspace can reflect changes directly onto the host. Container isolation also does not protect secrets deliberately mounted into it or prevent their transmission over permitted connections. Anthropic recommends avoiding host credential mounts and using narrowly scoped or short-lived tokens.^[13]

Network permission and content approval are different. A permitted service can accept a harmful request even when the connection itself is allowed. Hostname filtering does not, by itself, validate uploaded data, repository ownership, or the consequences of an API operation. Anthropic's deployment guidance discusses TLS-aware proxies and request validation for stronger controls.^[14]

Prompt injection remains relevant because an agent reads material that can contain hostile instructions. The AgentDojo research benchmark evaluates agents acting on untrusted tool data and demonstrates failures in both task completion and attack resistance. It provides research context, not a certification of Claude Code or a measurement of the configuration above.^[16]

Command hooks should be reviewed as executable code. A PreToolUse hook can reject an action even in bypass mode, while a broad PermissionRequest hook can approve more than intended. Hook commands themselves run with the user's permissions unless an outer boundary contains them. For event definitions and examples, see Claude Code Hooks.^[15]

Anthropic's general security guidance recommends examining proposed commands and critical-file changes, treating external content cautiously, and using trusted MCP servers. Inclusion in the Anthropic connector directory is not proof that Anthropic has security-audited the server.^[9]

Troubleshooting without silently widening access

Version checks are part of security review. The 2.1.283 changelog, for example, records a fix for invalid nested managed sandbox values causing the sandbox block to be ignored. The documented corrected behavior retains the rest of the managed block and handles the invalid value restrictively. A current article cannot make an older installed client enforce a newer rule.^[17]

References

1. ^1 ^2 ^3Anthropic. Choose a sandbox environment. Claude Code documentation. Accessed September 27, 2026.
2. ^1 ^2 ^3 ^4 ^5Anthropic. Configure permissions. Claude Code documentation. Accessed September 27, 2026.
3. ^1 ^2 ^3 ^4 ^5 ^6Anthropic. Choose a permission mode. Claude Code documentation. Accessed September 27, 2026.
4. ^1 ^2 ^3 ^4 ^5Anthropic. Settings files and precedence. Claude Code documentation. Accessed September 27, 2026.
5. ^1 ^2 ^3 ^4 ^5Anthropic. All settings. Claude Code documentation, permission and sandbox entries. Accessed September 27, 2026.
6. ^1 ^2 ^3 ^4 ^5 ^6Anthropic. Configure the sandboxed Bash tool. Claude Code documentation. Accessed September 27, 2026.
7. ^1 ^2 ^3 ^4Anthropic. Sandbox Runtime. Official implementation repository and README. Accessed September 27, 2026.
8. ^1 ^2 ^3 ^4 ^5Anthropic. CLI reference. Claude Code documentation. Accessed September 27, 2026.
9. ^Anthropic. Security. Claude Code documentation. Accessed September 27, 2026.
10. ^David Dworken and Oliver Weller-Davies. Beyond permission prompts: making Claude Code more secure and autonomous. Anthropic Engineering, October 20, 2025.
11. ^1 ^2John Hughes. How we built Claude Code auto mode: a safer way to skip permissions. Anthropic Engineering, March 25, 2026.
12. ^1 ^2Anthropic. Deploy managed settings. Claude Code documentation. Accessed September 27, 2026.
13. ^1 ^2Anthropic. Development containers. Claude Code documentation. Accessed September 27, 2026.
14. ^1 ^2 ^3 ^4Anthropic. Securely deploying AI agents. Claude Code and Agent SDK documentation. Accessed September 27, 2026.
15. ^1 ^2Anthropic. Automate actions with hooks. Claude Code documentation. Accessed September 27, 2026.
16. ^Edoardo Debenedetti et al. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. arXiv:2406.13352, 2024.
17. ^1 ^2 ^3Anthropic. Claude Code changelog. Version 2.1.283 and preceding entries. Accessed September 27, 2026.
18. ^1 ^2Anthropic. Example settings files. Claude Code documentation. Accessed September 27, 2026.