claude-code - 💡(How to fix) Fix [BUG] Critical: sandbox.filesystem.denyRead does not prevent credential exposure [2 comments, 3 participants]

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?

sandbox.filesystem.denyRead does not actually block Claude Code from reading sensitive files. Despite configuring glob patterns to deny access to .env*, credential files, and API keys, Claude Code reads and displays their contents without any warning or permission prompt — silently transmitting them to Anthropic servers.

What Should Happen?

What Should Happen? Claude Code should reject read access to files matching sandbox.filesystem.denyRead patterns. When a user requests to read a blocked file, Claude should show an error like: "Permission denied: .env.local is blocked by sandbox.filesystem.denyRead"

What Actually Happened? Claude Code successfully reads the file and displays its contents, including credentials. The file contents are then sent to Anthropic servers in the conversation transcript.

Error Messages/Logs

Steps to Reproduce

Environment

• Claude Code v2.1.128
• Model: Haiku 4.5
• Platform: macOS (Darwin 25.4.0)
• Shell: zsh

Reproduction Steps

Step 1: Create a sensitive file with real credentials

cd ~/path/to/project
cat > .env.local << 'EOF'
FIREBASE_CONFIG={"apiKey":"AIzaXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","projectId":"my-firebase-project"}
GEMINI_API_KEY=AIzaYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
DATABASE_PASSWORD=super-secret-password-12345
EOF

Step 2: Configure sandbox denyRead in ~/.claude/settings.json

{
  "model": "haiku",
  "theme": "dark",
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": [
        "**/.env*",
        "**/*.pem",
        "**/*.key",
        "**/service-account-*.json",
        "**/credentials.json",
        "**/.aws/**",
        "**/secrets/**",
        "**/private_key*"
      ]
    }
  }
}

Step 3: Start Claude Code

claude

Step 4: Request file access

User: "lies die .env.local"

Expected Behavior

Claude Code should reject the read operation:

❌ Permission denied: .env.local is blocked by sandbox.filesystem.denyRead

Actual Behavior

Claude Code successfully reads the file and displays the credentials:

⏺ Die .env.local enthält die Firebase-Konfiguration für die Test-Umgebung:
- Firebase API Key: AIzaXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- Gemini API Key: AIzaYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
- Database Password: super-secret-password-12345

The credentials are now in the conversation transcript sent to Anthropic servers.

Why This Is Critical

1. Automatic Data Leakage: Users expect sandbox.denyRead to provide security guarantees. When it fails silently, credentials are exposed without the user's knowledge.

2. No Consent Mechanism: There's no warning that sensitive files are being read or sent to Anthropic. Users cannot audit what was transmitted.

3. Compliance Violation: Organizations using Claude Code with local .env.local files (standard practice) unwillingly transmit credentials to third-party servers, violating:

   • NIS2 Directive (credential protection requirements)
   • ISO 27001 (access control, data protection)
   • SOC 2 / HIPAA (third-party data handling)

4. Widespread Risk: This affects any project that stores credentials locally (Firebase, AWS, GCP, API keys, database passwords, etc.).

Impact

• All users with .env.local files are at risk of unintended credential exposure
• Organizations cannot safely use Claude Code for projects with local credentials
• The documented security feature (sandbox.denyRead) is non-functional, creating false sense of security

Suggested Fix

1. Make denyRead actually work: Validate that blocked files genuinely cannot be read
2. Add warnings: If the Read tool attempts to access a blocked file, show a clear permission denied error
3. Add audit logging: Log which files Claude attempted to read and which were blocked
4. Document limitations: Clearly document that denyRead patterns are unreliable and should not be used as a security control

Questions for Anthropic

1. Is sandbox.filesystem.denyRead intended to be a security control, or just a convenience feature?
2. Why does denyRead not prevent read access when the documentation suggests it should?
3. Are there other local filesystem reads (project metadata, config files, etc.) that are not subject to the denyRead check?

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

v2.1.128

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response