Claude Code의 sandbox.denyRead는 읽기 도구를 중지하지 않습니다.

Type /sandbox in your Claude Code session right now. If you've never run it, every bash command Claude runs has the same access your terminal does. The sandbox is off until you turn it on. The Anthropic docs say so. Sandboxing is real OS-level isolation. It's built on the same tech Chrome uses to lock down each browser tab. I ran /sandbox for the first time last week because I wanted to know three things. Does it work? What does it actually protect? And can I finally unalias --dangerously-skip-permissions ? So I ran the experiments. Four findings: Filesystem writes are kernel-blocked. Write outside your working directory and you get Operation not permitted at the syscall level. No dialog to click through.Network isolation runs through a local proxy, not kernel blocking. Well-behaved HTTP clients route through a localhost proxy that checks the allowlist and returns CONNECT 403 for denied domains. Tools that ignore proxy env vars fall through to a Seatbelt backstop that blocks non-loopback traffic at the socket layer.Sandboxing is opt-in. You have to run /sandbox and pick a mode. If you haven't, your sandbox is off.sandbox.denyRead does not stop Claude's Read tool. This is the sharpest finding. A setting the docs imply should block reads has no effect on the Read tool. I verified it with headless Claude and stream-json tool traces. The fix is a separate permission rule the docs don't clearly connect to the sandbox setting. The fourth one I didn't expect. What sandboxing actually is Without sandboxing, Claude Code's bash tool is just bash. When Claude runs curl , it can reach any domain your machine can. When Claude runs cat ~/.ssh/id_rsa , it gets your SSH key. The only thing in the way is a permission prompt. A dialog box you can auto-approve, configure away, or click through without reading. Sandboxing takes the dialog out of it. The kernel blocks writes outside your working directory. Network traffic routes through a local proxy that checks an allowlist, and any tool that tries to bypass the proxy hits a kernel block on non-loopback traffic. No "do you want to allow Claude to..." prompt. Just syscalls that fail like any other permission error and a proxy that returns 403 for disallowed hosts. The tech is older than you might think. macOS ships with a framework called Seatbelt (internally, TrustedBSD MAC). Apple uses it to lock down Chrome renderer processes, iOS apps, and most of the system services that come with the OS. You can run it yourself from the command line: sandbox-exec -p '' bash -c 'whatever' . Claude Code wraps this primitive. Linux has a similar story with bubblewrap, the same sandbox Flatpak uses for third-party apps. WSL2 works because it's real Linux. WSL1 doesn't, because bubblewrap needs kernel features WSL1 can't give it. The mental model to carry: permissions ask you to say yes or no, and sandboxing removes the question. The kernel doesn't let it happen at all. Free Claude Code crash course Permissions vs sandboxing Permissions | Sandboxing | | |---|---|---| Scope | All tools: Read, Edit, Bash, WebFetch, MCP | Bash and its subprocess tree | Enforcement | Claude Code checks before running the tool | OS kernel for filesystem, local HTTP/SOCKS proxy for network | On violation | Prompts user for approval | | Bypassable by model? | If user approves | No, it's not a dialog | These two layers don't cover the same ground. Most people assume they do. That's why this post exists. Is it on by default? No. The Anthropic docs say you have to enable it yourself. You run /sandbox inside Claude Code, pick a mode from the menu, and you're in. If you've never run it, your sandbox is off. On macOS it works out of the box. Seatbelt ships with the OS. On Linux or WSL2 you need bubblewrap and socat first (sudo apt install bubblewrap socat on Debian/Ubuntu). The fallback is soft. If the sandbox can't start for any reason, missing dependencies or an unsupported platform, Claude Code prints a warning and runs your commands unsandboxed. For teams that want a hard gate, there's a sandbox.failIfUnavailable: true setting that turns the warning into an error. There are two modes. In auto-allow, bash commands run inside the sandbox without asking. If a command can't be sandboxed (it needs an excluded tool or an unlisted host), it falls back to the regular permission flow. This is the mode that replaces --dangerously-skip-permissions for bash. The docs are explicit: Auto-allow mode works independently of your permission mode setting. Even if you're not in "accept edits" mode, sandboxed bash commands will run automatically when auto-allow is enabled. In regular-permissions mode, the sandbox is on but you still approve each command. You see fewer prompts than you would without the sandbox, because denied operations fail directly instead of asking. You still see a prompt for the allowed stuff. This is the safety-net mode. Either way, the filesystem and network rules are identical. The only difference is whether sandbox