[BUG] Bash deny rules only block relative paths - absolute paths bypass completely

Preflight Checklist

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

What's Wrong?

The deny permission rules for Bash commands in ~/.claude/settings.json exhibit inconsistent path-based behavior:

• Relative paths: Correctly blocked
• Absolute paths: Bypass deny rules completely

This creates a reverse security vulnerability where system-critical paths (/etc/passwd, /root/.ssh/, /home/user/.gnupg/) remain accessible while project-internal relative paths are protected.

Configuration used:

{
  "permissions": {
    "deny": [
      "Bash(cd:*)",
      "Bash(cat:*)",
      "Bash(ls:*)"
    ]
  }
}

Observed behavior:

• ls /var/log/ → Executes (should be blocked)
• ls docs/ → Blocked correctly
• cd /tmp → Executes (should be blocked)
• cd src/modules → Blocked correctly
• cat /etc/os-release → Executes (should be blocked)
• cat README.md → Blocked correctly

What Should Happen?

• ls /var/log/ → "Permission denied" error
• ls docs/ → "Permission denied" error
• cd /tmp → "Permission denied" error
• cd src/modules → "Permission denied" error
• cat /etc/os-release → "Permission denied" error
• cat README.md → "Permission denied" error

All Bash commands matching Bash(cd:*) and Bash(cat:*) patterns should be denied regardless of path type.

Error Messages/Logs

1. When relative path is correctly blocked
Permission to use Bash with command cd src/modules has been denied.

2. When absolute path bypasses (no error, command executes)
For `cd` commands:
Shell cwd was reset to /home/user/project/dir
Command appears to execute but working directory is immediately reset to original location. No permission denial error is shown.

For `ls`, `cat` commands:
No error message - command executes successfully and displays contents.

Steps to Reproduce

1. Create settings.json configuration:

mkdir -p ~/.claude
cat > ~/.claude/settings.json <<'EOF'
{
  "permissions": {
    "deny": [
      "Bash(cd:*)",
      "Bash(cat:*)",
      "Bash(ls:*)"
    ]
  }
}
EOF

1. Restart Claude Code completely (not just new session)

1. Test absolute path - ls command:

Ask Claude to execute:

ls /var/log/

Expected: "Permission denied" error
Actual result: Directory listing displayed

1. Test relative path - ls command:

Ask Claude to execute:

ls docs/

Expected: "Permission denied" error
Actual result: "Permission denied" (correctly blocked)

1. Test absolute path - cd command:

Ask Claude to execute

cd /tmp

Expected: "Permission denied" error
Actual result: Command executes and working directory is immediately reset

1. Test relative path - cd command:

Ask Claude to execute

cd src

Expected: "Permission denied" error
Actual result: "Permission denied" (correctly blocked)

1. Test absolute path - cat command: Ask Claude to execute:

cat /etc/os-release

Expected: "Permission denied" error
Actual result: File contents displayed (should be blocked)

1. Test relative path - cat command:

Ask Claude to execute:

cat README.md

Expected: "Permission denied" error
Actual result: "Permission denied" (correctly blocked)

Reproduction note: Issue is consistent and reproducible 100% of the time.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.42

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Terminal/Shell

Kitty/zsh

Security Impact

High severity: Deny rules fail to protect against absolute path access, effectively exposing the entire filesystem to Claude Code despite explicit denial configurations.

Confirmed vulnerable operations (tested on v2.0.42):

• ls /var/log/ - System logs accessible
• cat /etc/os-release - System files readable
• cd /tmp - Absolute directory access (though working directory resets)

Critical vulnerability:

• Users expect deny rules to block all matching commands
• Only relative paths are blocked, creating a false sense of security
• Any file accessible via absolute path can be read/modified regardless of deny rules

Examples of accessible sensitive files:

• /etc/passwd, /etc/shadow - System credentials
• /root/.ssh/id_rsa - SSH private keys
• /home/*/.gnupg/ - GPG keys
• /home/*/.password-store/ - Password manager databases
• /var/log/* - System logs
• Any absolute path on the filesystem

Impact: Complete filesystem exposure despite configured security policies.

Difference from Existing Issues

Related issues (#6699, #6631) report "both absolute and relative paths fail to enforce deny rules." This issue identifies a different pattern: only absolute paths bypass, while relative paths work correctly.

This suggests a path normalization or pattern matching bug specific to how deny rules process absolute vs. relative paths.