When a coding agent runs without permission prompts, the isolation boundary is what protects your system. Anthropic's documentation says to run such Claude Code sessions inside a container, a VM, or the sandbox runtime, so that file tools, MCP servers, and hooks are inside the boundary, and to run them as a non-root user. The Bash sandbox alone is not sufficient.
Why prompts matter
A permission prompt is a person checking each action. Permission modes decide whether a tool call runs and whether you are asked first. Isolation does a different job: it limits what a command can reach once it runs. The documentation says the two work together. When a mode lets actions run without asking, an isolation boundary limits what those actions can reach.
With the flag that skips permission prompts, Claude acts without asking. The documentation states plainly that with no prompts to catch mistakes, the boundary you choose is what protects your system. On Linux and macOS, Claude Code refuses to start with that flag when running as root, so the container, VM, or runtime must run as a non-root user.
Auto mode is different
Auto mode replaces the prompt with a classifier that reviews actions. The documentation describes the classifier as a per-action control, not an isolation boundary, so an isolation boundary still adds defense in depth, though it is not required in the same way. This is a useful distinction for policy: skipping prompts entirely requires a boundary, while classifier review benefits from one.
What counts as a boundary
| Setup | Counts as a boundary for skipped prompts? | Why |
|---|---|---|
| Bash sandbox only | Not sufficient | Constrains shell commands only, file tools and MCP servers run outside |
| Sandbox runtime | Yes | Wraps the whole process |
| Dev container with firewall | Yes | Whole environment, default deny egress in the example |
| Custom container | Yes, if configured well | Depends on mounts, credentials, network policy |
| Virtual machine | Yes | Separate kernel |
| Cloud session | Yes | Full VM hosted by the provider, with proxy and allowlist |
A worked example: setting up an overnight run
An illustrative plan for a team that wants an agent to work through a backlog of flaky tests overnight.
- Pick a boundary. They choose the preconfigured dev container, which the documentation describes as including a default deny firewall.
- Start as non-root. The container user is not root, which the flag requires anyway.
- Mount carefully. Only the project directory is mounted writable. No home directory, no container socket, no cloud credentials.
- Tighten the firewall allowlist. They keep the model endpoint, the package registry they use, and nothing else.
- Remove standing credentials. Git pushes use a short lived token limited to one repository.
- Test. They ask the agent to read a file outside the project, reach an unlisted host, and push to a protected branch. All fail.
- Run. They let it work, and require pull request review the next morning.
- Review. The next day they read the changed files list first, then the session record.
Questions to ask about any container you use for this
- What is mounted writable?
- Which credentials and tokens are reachable inside it?
- What does the network policy allow?
- Does it run as non-root?
- Can the agent reach the host's runtime socket or metadata address?
The documentation gives the same checklist for any container you operate: review what is mounted writable, which credentials and tokens are reachable, and what egress is allowed.
What isolation still does not do
- It does not stop leaks over allowed network paths. The documentation warns that any approach that allows egress can still leak data the agent can read.
- It does not protect a writable project. The agent can still modify the code you mounted.
- It does not change what goes to the model. Prompts and files read are still sent to the model provider.
Team policy language you can adopt
- Sessions that skip permission prompts must run inside an approved boundary: sandbox runtime, container, VM, or cloud session.
- The boundary runs as a non-root user.
- Only the project directory is writable. No credentials beyond a task scoped token.
- Network access is default deny with a documented allowlist.
- Output is a branch and a pull request that a person reviews.
- Exceptions are recorded with an owner and an expiry date.
Enforcement
Claude Code enforces only the built-in Bash sandbox through managed settings. For containers and VMs, enforcement is a matter of your device management or software allowlisting, since Claude Code does not require a container. If it matters that developers cannot skip the boundary, plan for that outside the tool.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a gate decides whether a change may proceed, since unattended output needs a check before it merges.
Where Safeguard fits
Safeguard does not provide the isolation boundary. Its policies and gates evaluate changes agents propose, its agent identity and MCP Guardrail cover what agents and tools may do, and its CLI, which can write code as well as scan, can run inside the same kind of boundary.
Quick check
Can I skip permission prompts if I turn on the Bash sandbox?
Not safely on its own. The documentation says the Bash sandbox constrains only shell commands, so it is not sufficient for fully unattended runs.
Is auto mode the same as skipping prompts?
No. Auto mode uses a classifier to review actions. The documentation calls it a per-action control, not an isolation boundary, so a boundary still adds defense in depth.
Why run the container as non-root?
The flag refuses to start as root on Linux and macOS, and a non-root user also limits damage if the boundary is weaker than expected.
Sources
- Choose a sandbox environment (Anthropic documentation)
- Configure the sandboxed Bash tool (Anthropic documentation)
Last reviewed: 19 October 2026.
