No. An approval prompt asks you before the agent's file tools touch paths outside the project, but it is a prompt, not a wall. If you approve a shell command, that command can still write anywhere your user account can. To enforce a boundary at the operating system level, turn on a sandbox.
Definitions
Working directory boundary. In Claude Code's manual mode, the agent asks before its file tools read or write outside the folder where it started and its subfolders.
Sandbox. An operating system enforced boundary around shell commands, limiting the files and network hosts they can reach.
Permission rule. An allow, ask or deny rule that applies to a tool or command pattern.
The facts here come from Claude Code's own documentation. Other tools differ, so check yours.
Prompt versus sandbox
| Aspect | Permission prompt | Sandbox |
|---|---|---|
| Who enforces | The application, by asking you | The operating system |
| Can an approved command escape? | Yes, it runs with your account's access | Writes are limited to allowed paths |
| Prompt fatigue | Grows with use | Lets allowed commands run without asking |
| Covers file tools and MCP servers? | File tools follow permission rules | No, those run outside the sandbox |
What the sandbox does by default
Per the documentation, sandboxed commands can write to the working directory, a per-user temp directory and directories you add. Reads cover most of the machine, including credential files such as the SSH folder and cloud credentials, unless you add deny rules. Network access goes through a proxy that checks each host against an allowed list that starts empty. Environment variables, including secrets, are inherited unless you scrub them.
It runs on macOS, Linux and WSL2. On native Windows, commands run unsandboxed.
What stays outside the sandbox
The documentation lists several things: built-in file and web tools, hooks, local MCP servers, plugin monitors, language servers and helper commands. They run with your full access. Commands you type yourself at the shell prompt run unsandboxed in most sessions, and the agent can ask to retry a failed command unsandboxed.
Steps to tighten it
- Turn on the sandbox and choose whether sandboxed commands run without prompts.
- Add deny rules for credential directories, since reads are broad by default.
- Keep the allowed network domains short.
- Decide whether unsandboxed retries are allowed.
- For file tools and local MCP servers, use permission rules and review the servers you add.
- For a single boundary around everything, run the whole agent process inside a container or virtual machine.
Quick check
Does a deny rule on a file stop every tool reading it?
Not necessarily. The documentation notes that a read deny entry for the sandbox does not stop the Read tool, which follows permission rules. Set both.
Is a container better than the built-in sandbox?
A container or virtual machine can wrap the tools and processes the built-in sandbox leaves outside. The trade is setup effort.
Should I use a mode that skips all prompts?
The documentation recommends the bypass mode for isolated containers and virtual machines only.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for agent activity and scans repositories for vulnerable dependencies. Run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
