Claude Code Security: Check What Permissions, Hooks and Sandboxing Cover

A repository instruction can tell a coding agent to leave secrets alone. Whether a file read, script or outbound request is actually blocked depends on the control handling that action. For Claude Code users, the practical task is to map each rule to its enforcement path.

Anthropic’s best-practices guide distinguishes guidance in CLAUDE.md from controls applied by Claude Code itself. Keep project conventions and verification commands in that file. For a rule that must hold regardless of the model’s interpretation, choose an appropriate permission rule, policy hook or managed setting. Then check what that control covers.

Test file and network rules against each tool

The permission reference says file deny rules cover built-in file tools and recognized shell operations such as cat. They do not cover arbitrary Python or Node scripts opening files indirectly. A domain restriction on WebFetch likewise does not prevent a shell command from using curl to reach it.

Use a dummy secrets file in a disposable workspace to check the paths you actually permit: a file-tool read, a recognized shell read and a small script. Record each result. Where shell subprocesses must be blocked from a path, configure the corresponding sandbox filesystem restriction alongside the file-tool rule.

Make policy hooks fail closed

Anthropic’s hooks reference documents onFailure: "block" for command and HTTP hooks in Claude Code v2.1.295 and later. Without that setting, many failures or timeouts leave the action to continue through the normal permission flow. The field has no effect on Stop hooks.

Choose the event to match the purpose: a policy check needs to run before the action it guards; an after-edit formatter performs a different job. Test a deliberate denial and a checker failure, as well as a permitted action. A missing policy script should produce the outcome your team expects.

Check the boundary outside the shell

The sandbox documentation describes operating-system restrictions around shell commands and their descendants. Built-in file tools, MCP servers and hooks run outside that boundary. The built-in sandbox runs on macOS, Linux and WSL2; native Windows commands run unsandboxed.

Turning it on also does not automatically hide every secret: the documented default permits reads across most of the machine. Configure protected read paths explicitly. Inventory the access held by hooks and MCP servers separately. For a boundary around the entire Claude Code process, the documentation points to options such as a container or virtual machine.

For a team rollout, keep a compact control record: client version, operating system, protected path or destination, tool used, expected result and observed outcome. Repeat the relevant checks after configuration or client changes. This guide is based on documentation review; DaySec has not independently tested these controls.

Documentation reviewed November 9, 2026. This is a practical reference guide, rather than a new release announcement.

Latest articles

Related articles