[BUG] Deny rules in settings.json are not enforced — denied files and commands remain accessible`
Resolved 💬 3 comments Opened Jun 2, 2026 by Ethan-Sokn Closed Jun 2, 2026
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?
Deny permission rules in .claude/settings.json are not being enforced. Files listed under "deny" can still be read and written without any prompt or block.
What Should Happen?
Any tool call targeting a path or command matched by a deny rule should be blocked outright — the tool should not execute and Claude should not be able to access the file or run the command.
Error Messages/Logs
Steps to Reproduce
- In a workspace root, create .claude/settings.json with a deny rule for a specific file:
{
"permissions": {
"deny": ["Read(my-repo/.env)"]
}
}
- In a Claude Code session rooted at that workspace, attempt to read the denied file:
Read /workspace/my-repo/.env
- Observe that the file is read successfully with no prompt or block.
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.160
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
Additional context discovered during investigation:
- The deny rules were first placed in a repo-level .claude/settings.json at my-repo/.claude/settings.json. They had no effect — likely because the session root was the parent workspace directory, so the repo-level settings file was never loaded.
- The deny rules were then moved to the workspace-level .claude/settings.json. They still had no effect — even with no conflicting allow rule present.
- Deny rules appear to be non-functional regardless of where they are placed or whether an allow conflict exists.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗