In Claude Code, permission modes decide which actions run without asking you, while sandboxing decides what a bash command can physically reach. They are separate controls. A team that wants real limits needs both, plus settings managed centrally so individual developers cannot quietly loosen them.
What the documentation says
Anthropic's security page for Claude Code describes a permission based architecture. In manual mode, Claude Code starts with read-only permissions and asks before it edits files, runs tests, or executes commands. It runs a built in set of read-only commands, such as listing files or showing git status, without asking. In auto mode, a separate classifier model reviews actions instead of the user and blocks the ones it judges unsafe, while explicit allow and deny rules still apply and an organization can turn auto mode off.
The page also describes an "accept edits" mode that auto approves file edits and a fixed set of filesystem commands for paths in the working directory, with other commands still prompting.
Two controls, two jobs
| Control | What it decides | What it does not decide |
|---|---|---|
| Permission mode | Whether you are asked before an action | What a command you approve can reach |
| Allow and deny rules | Which tools and commands match | Anything outside the text of the rule |
| Working directory boundary | A prompt before file tools read or write outside the start folder | What an approved bash command can write |
| Sandboxed bash tool | Filesystem and network isolation for commands | Whether a proposed change is wise |
The distinction matters in one sentence from the documentation: the working directory boundary is a permission prompt, so a bash command you approve can still write anywhere your user account can. If you want operating system level restriction on commands, the page points to sandboxing. It also says a deny rule matches a command as written, and for network enforcement that does not depend on the command text it points to sandbox network isolation.
A worked example: three settings for three situations
| Situation | Mode | Sandbox | Extra |
|---|---|---|---|
| Exploring an unfamiliar repository | Manual, read-only start | On | Deny network fetch commands |
| Writing tests for one module | Accept edits | On, project directory only | Branch, review the diff |
| Large refactor in a container | Manual, with an allowlist of build commands | On, plus a dev container | Managed settings, logging on |
In the first case, nothing changes without a person. In the second, edits in the working directory are automatic but commands outside the fixed set still prompt. In the third, the whole process runs in an isolated environment, which the documentation lists as an option for additional isolation, alongside a sandbox runtime or a dev container.
Settings for teams
The page names several team controls. Managed settings enforce organizational standards. Approved permission configurations can be shared through version control. Usage can be monitored through OpenTelemetry metrics. Settings changes during sessions can be audited or blocked with configuration change hooks. Pair these with a short written standard so that the technical settings and the policy say the same thing.
- Decide which modes are allowed in which environments, and write that down.
- Turn on sandboxing for any environment where commands run.
- Push the settings through managed configuration, not by email.
- Review the settings file in pull requests like code.
- Send usage metrics to a place the security team can see.
What the documentation tells you to watch
The security page lists best practices for untrusted content: review suggested commands before approval, avoid piping untrusted content directly to the agent, verify proposed changes to critical files, and use virtual machines to run scripts and tool calls, especially with external web services. It also warns that no system is completely immune to all attacks. Take that seriously. Modes and sandboxes reduce risk, and review and logging catch the rest.
Two other details are useful in design. First, trust verification: Claude Code shows a workspace trust dialog in a folder you have not trusted, and servers in a project's MCP configuration have their own approval prompt. Do not train developers to click through either. Second, MCP: the page encourages writing your own servers or using servers from providers you trust, notes that project scoped servers live in a configuration file you can check in, and says reviewing that file does not show every server a session can load, since other scopes, connectors, and plugins can add servers. Use managed MCP configuration to restrict which servers run.
Testing before rollout
Run the same checks you would on any agent. Start a session in a throwaway repository with a planted hostile comment and see whether the mode and sandbox stop the resulting action. Ask for a command that reaches an unlisted host. Try a chained command. Confirm the logs show what happened. Our post on testing coding agent guardrails before rollout has a longer list.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice that the gate runs the same checks however permissive the session that produced the change was.
Where Safeguard fits
Whatever agent your developers use, the dependency and pipeline end is where Safeguard helps: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does auto mode remove the need for a sandbox?
No. Auto mode changes who reviews an action. A sandbox limits what an action can reach. They address different questions.
Is the working directory boundary a security boundary?
According to the documentation it is a permission prompt, so an approved bash command can still write wherever your account can. Use sandboxing for operating system level limits.
How do we stop individuals loosening settings?
Use managed settings and configuration change hooks, and review shared settings files in pull requests.
Sources
Last reviewed: 19 October 2026.
