OS-Level Sandboxing: The Residual Control Beneath Hooks

The Dependency Hooks Share

Hooks and least-privilege permission roles are enforced, deterministic controls -- but they share a dependency worth stating plainly: each one only protects the path or endpoint it was explicitly written to cover. A PreToolUse hook that checks write_file calls does not automatically block an outbound network call to an endpoint nobody thought to write a rule for. If a hook is missing a case, misconfigured, or has a bug, the tool call it should have caught simply goes through -- the hook is a rule-level control, and a rule that was never written protects nothing.

What OS-Level Sandboxing Adds

OS-level sandboxing closes that specific gap by moving enforcement down a level -- from application logic (a hook checking a specific case) to the operating system itself (a boundary that holds no matter what any individual hook does or doesn't cover):

• Filesystem isolation -- confines the agent's process to a designated working directory as an OS-enforced boundary, so a hook gap or an omitted check in application code never opens a path outside it
• Network isolation -- limits the process to an approved allowlist of outbound destinations at the kernel/network layer, so an identity role that (mistakenly or otherwise) permits broader access still cannot reach an endpoint outside that allowlist

Both are enforced by the operating system, independent of whether the application-level hook logic is correct, complete, or even present. That independence is the entire point: a hook can be missing, misconfigured, or bypassed, and the OS-level boundary still holds, because it was never depending on the hook being right in the first place.

Defense-in-Depth's Last Line

Frame this as the final layer in the stack this domain has been building: model-side training and input classifiers cut down how many injection attempts even land; the data-not-instructions framing cuts down how often a landed attempt actually gets acted on; least privilege and hooks then cap and log what a successful action is able to touch. OS-level sandboxing sits underneath every one of those -- it's the reason a hook bug, or an endpoint nobody remembered to cover, doesn't turn into full compromise on its own. Each layer above it can fail independently without the whole stack collapsing at once.

Configuration for this control lives in Claude Code settings, with full documentation at code.claude.com -- it's a setting to configure once at the process/session level, not a rule to write per tool call.

Common exam traps

• Treating hooks as sufficient on their own because they're deterministic. Hooks are deterministic *for the cases they explicitly cover* -- an uncovered path or endpoint is not protected by a hook that was never written to check it.
• Assuming a security gap always means a hook was misconfigured. OS-level sandboxing exists precisely because hooks can be missing or buggy and the system should still hold -- that's a residual control, not a backup for human error alone.
• Forgetting that OS-level sandboxing covers two distinct surfaces -- filesystem *and* network -- not just one. A filesystem-only mental model misses that network isolation is doing separate, equally important work.