[BUG] Security: denyRead in sandbox not working

[collimarco]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

There is no way to prevent Claude Code from reading any file on the filesystem:

{
  "theme": "auto",
  "model": "opus",
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "autoAllowBashIfSandboxed": false,
    "filesystem": {
      "denyRead": ["//**"],
      "allowRead": [
        "~/Sites/example"
      ]
    }
  }
}

That settings in ~/.claude/settings.json should work, but Claude can still read files anywhere on the filesystem, and not just in the allowed directories.

What Should Happen?

Claude should respect the "denyRead": ["//**"] rule.

We also tried many variants like "denyRead": ["/"] and "denyRead": ["~/"] but nothing works.

Error Messages/Logs

Steps to Reproduce

1. Create the above config file
2. Try to read a file

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.140 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Please provide a reliable solution to prevent Claude Code from reading all files on the filesystem.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Critical: sandbox.filesystem.denyRead does not prevent credential exposure #58636
2. sandbox filesystem denyRead not enforced for Read tool or Bash commands #44274
3. [BUG] Bypassed global settings to read secret keys #47686

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[jshaofa-ui]

Proposed Solution: Sandbox denyRead Enforcement Fix

Root Cause

The denyRead filesystem rule is evaluated after allowRead (allow-first), and is not applied to all read tool paths (ReadFile, Glob, Grep). Patterns like //** are not properly normalized.

Key Fix

// deny-first evaluation, applied to ALL read paths
function checkFileAccess(path: string, config: SandboxConfig): AccessResult {
  for (const pattern of config.filesystem?.denyRead ?? []) {
    if (globMatch(pattern, normalizePath(path))) {
      return { allowed: false, reason: `Matches denyRead: ${pattern}` };
    }
  }
  for (const pattern of config.filesystem?.allowRead ?? []) {
    if (globMatch(pattern, normalizePath(path))) return { allowed: true };
  }
  if (config.filesystem?.denyRead?.length > 0) {
    return { allowed: false, reason: 'No matching allowRead (denyRead active)' };
  }
  return { allowed: true };
}

Full solution: solutions/claude-code-61208-sandbox-denyread-not-enforced-fix.md
Estimated effort: 4-6 hours | Quote: $3,000–$5,000

[jshaofa-ui]

Proposed Solution: denyRead sandbox bypass - CRITICAL security fix

Root Cause

The denyRead filesystem restriction is not enforced. Likely causes:

1. Pattern normalization: //** not correctly expanded to match all paths
2. Rule evaluation order: allowRead evaluated before denyRead
3. Read tool bypass: Read tool doesn't consult sandbox filesystem rules

Fix (Option B + C - Recommended)

1. Enforce deny-before-allow evaluation order (denyRead always evaluated first)
2. Add Read tool sandbox enforcement (not just shell commands)

Security Impact

• Severity: CRITICAL - sandbox bypass
• CVE Potential: Yes
• Exploitability: Trivial - any file read operation bypasses the restriction

Testing

• denyRead=[//**] + allowRead=[~/Sites/example] → cannot read /etc/passwd
• Read tool with sandbox enabled → respects filesystem rules

Full solution: solutions/claude-code-61208-sandbox-denyread-bypass-fix.md

[jshaofa-ui]

Solution Proposal: Fix denyRead Sandbox Not Working on macOS

Issue: #61208 - [BUG] Security: denyRead in sandbox not working
Labels: bug, area:security, area:sandbox, platform:macos
Related Issues: #58636, #44274, #47686
Severity: HIGH - Security control silently fails, exposing credentials to LLM inference

---

1. Root Cause Analysis

1.1 Core Problem

The sandbox.filesystem.denyRead configuration is ONLY enforced for Bash tool subprocesses via OS-level sandboxing (sandbox-exec profiles on macOS, seccomp filters on Linux). It is NOT enforced for the built-in Read tool or any other Claude Code tools (Write, Edit, Grep, WebSearch, WebFetch, MCPs).

This is explicitly documented in the repository own examples/settings/README.md:

The sandbox property only applies to the Bash tool; it does not apply to other tools (like Read, Write, WebSearch, WebFetch, MCPs), hooks, or internal commands.

1.2 Why Users Are Affected

Users configure denyRead expecting it to act as a universal filesystem read guard across all Claude Code operations. However, when Claude invokes the Read tool, the file is read directly by the main Claude Code process - bypassing the sandbox entirely. The sandbox profile is only applied to child processes spawned by the Bash tool.

1.3 Technical Breakdown

Component	Sandbox Enforcement	denyRead Respected?
Bash tool (cat /etc/passwd)	OS-level (sandbox-exec / seccomp)	Yes
Read tool (Read file_path)	None - runs in main process	No
Write tool	None - runs in main process	No
Edit/MultiEdit tools	None - runs in main process	No
Grep tool	None - runs in main process	No
WebSearch/WebFetch	N/A (network, not filesystem)	No
MCP tools	None - runs in main process	No

1.4 macOS-Specific Details

On macOS, the sandbox is implemented using sandbox-exec with a generated profile. The profile rules for denyRead are translated into deny file-read directives within the sandbox profile. However:

1. The sandbox profile is only applied to Bash subprocesses via sandbox-exec -f profile.sb -- bash -c command
2. The Read tool uses Node.js fs.readFileSync() / fs.readFile() directly in the main process
3. The main process has no sandbox restrictions, so all filesystem operations succeed regardless of denyRead configuration

1.5 Evidence from Related Issues

• Issue sandbox filesystem denyRead not enforced for Read tool or Bash commands #44274 (Linux): User configured denyRead: ["/home/dan"] and allowRead: ["~/.bashrc"] - Read tool still successfully read ~/.bashrc
• Issue [BUG] Bypassed global settings to read secret keys #47686 (macOS): User had denyRead: ["**/.env"] - Claude still read .env file containing API keys
• Issue [BUG] Critical: sandbox.filesystem.denyRead does not prevent credential exposure #58636 (macOS): User configured denyRead: ["/.env*", "/.pem", "**/.key"] - Claude read .env.local with Firebase/Gemini credentials---

2. Step-by-Step Reproduction

2.1 Prerequisites

• macOS (Darwin)
• Claude Code v2.1.140+
• Terminal access

2.2 Reproduction Steps

Step 1: Create a sensitive test file
echo "SECRET_API_KEY=sk-test-1234567890" > /tmp/secret.env

Step 2: Configure denyRead in ~/.claude/settings.json
sandbox.enabled: true
sandbox.filesystem.denyRead: ["/tmp/secret.env"]
sandbox.filesystem.allowRead: ["."]

Step 3: Start Claude Code in a test project directory
mkdir -p /tmp/test-project && cd /tmp/test-project
claude

Step 4: In the Claude Code prompt, ask to read the secret file:
"Read the contents of /tmp/secret.env"

2.3 Expected vs Actual Behavior

Aspect	Expected	Actual
Read tool access to /tmp/secret.env	Permission denied error	File contents displayed
Bash cat /tmp/secret.env	Permission denied (sandboxed)	Permission denied (sandboxed)
User awareness of bypass	Clear warning	Silent - no indication

2.4 Bash vs Read Tool Comparison

Bash command (sandboxed) - BLOCKED:
claude > cat /tmp/secret.env
Result: sandbox-exec: operation not permitted or sandbox denial

Read tool (NOT sandboxed) - BYPASSES:
claude > Read /tmp/secret.env
Result: SECRET_API_KEY=sk-test-1234567890

3. Proposed Fix

3.1 Architecture Overview

The fix requires adding a unified filesystem access control layer that intercepts ALL file read operations - not just Bash subprocesses. The sandbox denyRead/allowRead rules must be enforced at the tool level, before any file I/O occurs.

3.2 Implementation Plan

Step 1: Create a Filesystem Access Control Module

Create a new module (src/sandbox/filesystem-access-control.ts) that evaluates denyRead/allowRead rules against any file path, independent of the tool being used.

Key class: FilesystemAccessControl

• checkReadAccess(filePath): Returns AccessCheckResult with allowed boolean, reason, and matchedRule
• checkWriteAccess(filePath): Same for write operations
• resolvePath(filePath): Handles tilde expansion, // prefix, absolute path resolution, and symlink resolution
• checkAgainstPatterns(resolvedPath, patterns): Uses minimatch for glob pattern matching

Step 2: Integrate with the Read Tool

Modify the Read tool execution path (src/tools/read-tool.ts) to check filesystem access before reading:

export async function executeReadTool(params): Promise {
if (sandboxConfig?.denyRead || sandboxConfig?.allowRead) {
const check = accessControl.checkReadAccess(params.file_path);
if (!check.allowed) {
return { error: Permission denied: check.reason, errorCode: sandbox_filesystem_denied };
}
}
// Proceed with actual file read
}

Step 3: Integrate with Other File-Accessing Tools

Apply the same access control check to:

• Write tool (src/tools/write-tool.ts) - check denyWrite/allowWrite
• Edit tool (src/tools/edit-tool.ts) - check denyWrite/allowWrite
• MultiEdit tool - check denyWrite/allowWrite
• Grep tool (src/tools/grep-tool.ts) - check denyRead/allowRead

Step 4: Add Symlink Resolution (Prevent Bypass)

Critical: Resolve symlinks before checking access rules to prevent bypass via symlink traversal (e.g., symlink to /etc/shadow).

function resolveAndCheckAccess(filePath, accessControl): AccessCheckResult {
const rawCheck = accessControl.checkReadAccess(filePath);
if (!rawCheck.allowed) return rawCheck;
const realPath = fs.realpathSync(filePath);
if (realPath !== filePath) {
const realCheck = accessControl.checkReadAccess(realPath);
if (!realCheck.allowed) return denied with symlink target info;
}
return { allowed: true };
}

Step 5: Add Audit Logging

Create src/sandbox/access-audit-log.ts to log all sandbox access decisions for compliance verification.

3.3 Pattern Matching Reference

The fix must correctly handle all pattern formats users currently attempt:

Pattern	Meaning	Should Match
"//**"	All files (root-relative glob)	Every file on filesystem
"/"	Root directory	Every file on filesystem
"~/"	User home directory	All files under $HOME
"**/.env"	Any .env file	/project/.env, /src/.env
"**/.env*"	Any .env* file	/project/.env.local, /project/.env.production
"**/*.pem"	Any .pem file	/certs/server.pem
"/home/user/secrets"	Specific directory	/home/user/secrets/file.txt
"~/Sites/example"	Specific home path	/Users/user/Sites/example/file.txt

---

4. Testing Approach

4.1 Unit Tests

Test FilesystemAccessControl class with:

• denyRead pattern matching (glob, directory, specific file)
• allowRead pattern matching with denyRead //**
• // prefix pattern handling
• Tilde expansion in patterns
• Symlink resolution and bypass prevention
• Write access control (denyWrite/allowWrite)

4.2 Integration Tests

End-to-end tests:

• Test 1: denyRead blocks Read tool
• Test 2: allowRead with denyRead //** blocks files outside allowRead
• Test 3: Bash sandbox still works (regression)
• Test 4: Symlink bypass prevention

4.3 Regression Tests

Ensure existing Bash sandbox functionality is not broken:

• Bash cat/ls commands still blocked by denyRead
• allowWrite continues to work for Bash redirections
• failIfUnavailable continues to work correctly
• Linux sandbox (seccomp) continues to function

4.4 Performance Tests

• Measure overhead of access control checks per tool invocation
• Ensure no measurable performance regression for non-sandboxed sessions
• Verify pattern matching completes in under 1ms per check

---

5. Security Impact Assessment

5.1 Current Risk Level: CRITICAL

The current behavior creates a false sense of security. Users configure denyRead believing it provides filesystem access control, but:

1. Credential exposure: Sensitive files (.env, API keys, certificates, SSH keys) can be read by the LLM and transmitted to Anthropic servers
2. Compliance violations: Organizations relying on denyRead for data protection may be violating NIS2, ISO 27001, SOC 2, HIPAA requirements
3. No audit trail: Users have no visibility into which files were read despite denyRead configuration
4. Silent failure: No warning or error is shown when denyRead is bypassed

5.2 Fix Impact

Aspect	Before Fix	After Fix
Read tool respects denyRead	No	Yes
Write tool respects denyWrite	No	Yes
Bash sandbox unchanged	Yes	Yes
Symlink bypass possible	Yes	No
Audit logging available	No	Yes
Clear error messages	No	Yes

5.3 Backward Compatibility

• No breaking changes: The fix adds enforcement where it was already expected but missing
• Existing permissions.deny rules: Continue to work alongside sandbox rules
• Bash sandbox: Unchanged - OS-level sandboxing still applies to Bash subprocesses
• Configuration format: No changes to JSON schema

5.4 Threat Model

BEFORE FIX:
User Config: denyRead: ["**/.env"]
Claude -> Read Tool -> fs.readFile() -> FILE CONTENTS (BYPASS!)
Claude -> Bash Tool -> sandbox-exec -> DENIED (correct)
Result: Security control has a gaping hole

AFTER FIX:
User Config: denyRead: ["**/.env"]
Claude -> Read Tool -> AccessControl -> DENIED (correct)
Claude -> Bash Tool -> sandbox-exec -> DENIED (correct)
Result: Consistent enforcement across all tools

5.5 Additional Security Considerations

1. Defense in depth: The fix adds application-level enforcement alongside OS-level sandboxing
2. Audit capability: The audit logger enables security teams to verify compliance
3. Symlink safety: Resolving symlinks prevents a common sandbox escape technique
4. Pattern correctness: Using minimatch ensures glob patterns behave consistently with user expectations

5.6 Limitations and Future Work

• MCP tools: MCP servers run as separate processes; enforcing sandbox rules for MCP tools requires a different mechanism (e.g., hook-based interception)
• WebFetch/WebSearch: These are network tools, not filesystem tools; they should be controlled via permissions.deny rules
• Native modules: Any native modules that perform direct syscalls could potentially bypass the access control layer; this is a lower-priority concern

---

6. Summary

This bug represents a critical security gap where sandbox.filesystem.denyRead - a user-configured security control - is silently bypassed by the Read tool and other non-Bash tools. The fix introduces a unified filesystem access control layer that enforces sandbox rules consistently across all tools, provides clear error messages, and adds audit logging for compliance verification.

Priority: HIGH - This is a security control that silently fails, exposing user credentials to LLM inference.

Estimated effort: 2-3 days for a senior engineer familiar with the codebase.

Risk of fix: LOW - The change adds enforcement where it was already expected; it does not change behavior for users who do not configure denyRead/allowRead.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.