Claude Code's File Read Restriction Has a Gap Developers Should Know

Claude Code's sandboxing system has a meaningful gap: the sandbox.denyRead setting - designed to prevent the AI from reading files you mark as off-limits - doesn't actually block Claude Code's native Read tool.

Claude Code is Anthropic's AI coding assistant that runs in your terminal. It can read files, write and edit code, execute shell commands, and browse the web. That level of access is what makes it useful - and it's also why the access controls matter. The sandboxing system is how you set those controls: you configure rules about what Claude can and can't do, and Claude Code is supposed to respect them.

The sandbox.denyRead setting is specifically for file access. You add paths or patterns to it - your .env file, a private config directory, a folder containing API credentials - and expect that Claude Code won't read them. According to a technical analysis published by Claude Code Camp, that expectation doesn't hold.

Two Ways to Read a File, Only One Blocked

The gap comes down to how Claude Code reads files. There are two routes: using shell commands (like cat or less executed through the Bash tool), and using Claude Code's built-in Read tool, which directly accesses file contents without going through the shell.

sandbox.denyRead blocks the shell-command route. It doesn't apply to the Read tool. Since the Read tool is Claude's default method for reading files - the one it uses in normal operation, not as a workaround - the restrictions you set in denyRead don't prevent the access pattern you're actually concerned about.

This isn't a corner case. When Claude Code reads your project files to understand context before writing code, it's typically using the Read tool. If a path in your denyRead configuration falls within that context window, the restriction won't stop it.

Who Needs to Care

For a solo developer working on a project where all sensitive data lives outside the project directory, the gap is unlikely to cause problems. The risk surface is higher in specific situations:

• Sensitive files (.env, API keys, private configs) live inside or adjacent to your project directory
• You're running Claude Code in a team or CI/CD environment with broader filesystem access
• Your codebase mixes source code with private configuration files

The practical fixes available now:

• Move sensitive files outside your project directory entirely rather than trying to restrict access within it
• Use a .claudeignore file to exclude specific files from Claude's awareness at the project configuration level
• Don't treat sandbox.denyRead as a security boundary - treat it as a soft preference

The sandbox.denyRead gap reflects a broader challenge in AI agent security: documentation describes intended behavior, and users reasonably rely on it, but the implementation may not cover every code path. As AI coding tools get deployed in more sensitive environments - enterprise codebases, production pipelines, shared development servers - the distance between documented and actual behavior matters more. The safest approach with Claude Code right now is to assume read access is broad and structure your working environment accordingly, rather than relying on per-path restrictions.

Claude Code Camp's full writeup covers additional details on how the sandboxing system works and what it does and doesn't protect.