Claude Code ignores deny rules in .claude/settings.local.json - security vulnerability

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/8031
2. https://github.com/anthropics/claude-code/issues/2014
3. https://github.com/anthropics/claude-code/issues/7921

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

Also seeing the same issue, claude code latest version ignores the deny list and reads the file anyways. When Sonnet 4.5 is confronted and shown that there are explicit denies at both user and project level:

This is definitely a bug. The deny rules are properly configured at the user level, but they're not being enforced when I use the Read tool. I was able to read
  .tfvars files twice despite explicit denial rules.

  You should report this as a security issue at https://github.com/anthropics/claude-code/issues since sensitive credentials are being exposed when they shouldn't
  be.

Note: it doesn't just ignore Deny rules, it also ignores Allow rules too! The whole permissions setion is ignored. Other settings like statusline work fine, but all Allow and Deny rules that I have tested have no effect.

The "env" entry is also ignored.
"GOOGLE_APPLICATION_CREDENTIALS":.
is stored in a different location to that of the team member, we tried to configure it, but the settings.json works.
settings.json worked, while settings.local.json did not.

I'm finding the same sort of issue. Report attached.

report.txt

Finding the same issue. In my case, I want to review all code myself before a Git commit. From my Claude settings.json in my user directory:
"permissions": {
"deny": [
"Bash(git commit:*)",
"Bash(curl *)",
"Bash(wget *)",
"Bash(ssh *)",
"Bash(sudo *)"
],

Yet very often, Claude Code defies these rules and runs commits.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Yes it is still and issue. It is silly that I have to reopen this once a month. Since this is a security issue, I would have thought that Anthropic would be care about solving it.

I experienced a similar issue that may be related.

Environment:

• Claude Code (VS Code extension)
• OS: macOS 23.6.0

What happened:
My .claude/settings.json had invalid JSON (a trailing comma in the array), which caused the deny rules to be silently ignored. As a result, .env files containing sensitive credentials were accessible despite having explicit deny rules configured.

Key observation - inconsistent warning behavior:

• When I first opened the session with invalid JSON, no warning was displayed for settings.json
• Only a warning for settings.local.json appeared (a different file)
• After reopening the session later, the "Settings Error: Invalid or malformed JSON" warning finally appeared

This inconsistency made debugging very confusing - I initially thought the deny rules themselves were broken, not realizing the settings file had a syntax error that was being silently ignored.

Expected behavior:
The warning for invalid JSON in settings.json should appear immediately and consistently when the file is loaded, not intermittently.

Impact:
Because the invalid settings were silently skipped, security-sensitive files (.env with API keys) were exposed when they should have been protected by deny rules.

@sanbongazin1123 that sounds like it probably deserves it's own issue.

Also it sounds like this bug isn't stale...

Confirmed today with a deny read rule for a config.json I had in settings.json file. Time to rotate keys...

@wizardmagick are you saying it's not just settings.local.json that claude is not respecting? And you're sure your deny rule is formatted correctly?

I'd like to add what weight I can here on this issue. My organization is considering moving to Anthropic/Claude code for our dev team but the initial issue in this thread (and others on the thread) is a huge blocker for us. We cannot swap tools until we have reasonable faith in the tools ability to protect sensitive information in our repositories. Until this is resolved I can't recommend we make this swap.

I've been trialing Claude with personal code and a personal account in dummy projects, and I love how effective it is. I want to swap and get on this train, I'll keep an eye on this thread to see if/when it is resolved so we can look more seriously at becoming a customer.

Claude is blocking my .env files with
"deny": [
"Read(**/.env)"
]

I've tried to use managed-settings.json in /etc/claude-code, but it fails in the same way.

I've tried to use managed-settings.json in /etc/claude-code, but it fails in the same way.

same

Workaround — PreToolUse hooks enforce denials where permission deny rules don't:

#!/bin/bash
# Hook-based deny that can't be ignored
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Add your deny patterns here
if echo "$CMD" | grep -qE 'rm\s+-rf|git\s+push\s+--force|git\s+reset\s+--hard'; then
    echo "BLOCKED by hook" >&2
    exit 2
fi
exit 0

Hooks with exit code 2 are a harder block than permission deny rules — they execute independently of the permission system and can't be overridden by project-level settings.

Quick install: npx cc-safe-setup — 8 hooks in user-level ~/.claude/settings.json that apply globally across all projects.

The deny rules in settings.local.json have known enforcement gaps. Hooks are the reliable deny mechanism:

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
[ -z "$FILE" ] && exit 0
if echo "$FILE" | grep -qE '\.env\.production'; then
    echo "BLOCKED: Cannot read production environment files." >&2
    exit 2
fi
exit 0

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
[ -z "$FILE" ] && exit 0
if echo "$FILE" | grep -qE '\.env\.production'; then
    echo "BLOCKED: Cannot edit production environment files." >&2
    exit 2
fi
exit 0

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0
if echo "$COMMAND" | grep -qE '(cat|less|more|head|tail|grep|source|\.)\s+.*\.env\.production'; then
    echo "BLOCKED: Cannot access production environment files via bash." >&2
    exit 2
fi
exit 0

{
  "hooks": {
    "PreToolUse": [
      {"matcher": "Read", "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/deny-read-env.sh"}]},
      {"matcher": "Edit", "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/deny-edit-env.sh"}]},
      {"matcher": "Write", "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/deny-edit-env.sh"}]},
      {"matcher": "Bash", "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/deny-bash-env.sh"}]}
    ]
  }
}

This covers all three access vectors: Read tool, Edit/Write tools, and Bash tool (cat, grep, source). exit 2 blocks the operation before execution — Claude can't read your production secrets regardless of what the deny rules in settings.local.json do or don't enforce.

Hooks are way better than the settings.json, I agree. But then we need to make exhaustive lists of what's not allowed. I got Claude a little bit annoyed a couple of days ago because it couldn't find gcc to build C-programs! So trying to tell Claude to not read a certain file of folder, is a Sisyphean task.
The only solution I've found is to put Claude in a container and map in the specific folders you want. See https://medium.com/@larma/containerizing-claude-ef722831fb10