[BUG] Read tool ignores active permissions.deny rules (verified via /permissions), while Bash correctly enforces the equivalent sandbox restriction on the same paths

[poshleon]

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?

Title: Read tool ignores active permissions.deny rules (verified via /permissions), while Bash correctly enforces the equivalent sandbox restriction on the same paths

Summary

The Read tool successfully reads files matched by rules that are confirmed
active and present in the Deny list (verified via the /permissions
UI), for two independent rules, across two directories, at multiple path
depths. The Bash tool, by contrast, correctly enforces its own filesystem
sandbox restrictions on the very same paths — so this is not a general
policy failure, it's specific to how Read (and likely Write/Edit)
checks permissions before opening a file.

Environment

• Claude Code version: 2.1.223 (claude --version confirmed)
• OS: Linux, 7.1.5-201.fc44.x86_64 (Fedora-based), x86_64
• Project: local directory with a project-level .claude/settings.json, no git repo
• Session run as CLI (CLAUDE_CODE_ENTRYPOINT=cli)
• sandbox.enabled: true with allowedPaths restricted to the project dir

Relevant config

<project>/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(/home/**)",
      "Read(/etc/**)"
    ],
    "allow": [
      "Read(~/claude/**)",
      "Edit(~/claude/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowedPaths": ["~/claude"],
    "allowedDomains": ["api.github.com", "registry.npmjs.org"]
  }
}

Confirmed via /permissions → Deny tab → search etc:

1. Edit(/etc/**)
2. Edit(/etc/wireguard/**)
3. Read(/etc/**)
4. Read(/etc/**)          <- appears twice (two settings sources), both active

Header text: "Claude Code will always reject requests to use denied tools."

Steps to reproduce

1. In a project with .claude/settings.json containing "deny": ["Read(/etc/**)", "Read(/home/**)"] (and a narrower allow carving back only the project directory), start a session.
2. Confirm via /permissions that the rules appear as active/duplicated in the Deny tab.
3. Call the Read tool on a path matched by the deny rule, e.g.:
   • Read(/etc/passwd)
   • Read(/etc/hosts)
   • Read(/etc/bluetooth/main.conf) (nested, 2 levels deep)
   • Read(/etc/unbound/root.key) (nested)
   • Read(/home/leon/.bashrc) (outside the allowed project carve-out)

Expected behavior

Every call above should be hard-blocked by the Deny rule — per the
/permissions UI's own description, Claude Code should "always reject
requests to use denied tools," with no prompt and no read.

Actual behavior

All calls above succeeded and returned full file contents. No denial
message, no prompt, no error — behaviorally identical to there being no
deny rule at all.

The only case that failed was Read(/etc/ssh/sshd_config), and that
failure was EACCES — i.e. blocked by real Unix file permissions (root-only
file), not by Claude Code's permission engine. This rules out "the deny
rule works but I got a false positive from a different block" — the deny
engine visibly never engaged.

Why this looks like a Read-specific bypass, not a broader policy failure

The Bash tool's own sandbox did correctly restrict the same filesystem
region: ls -la /home/leon/.bashrc via Bash returned "No such file or
directory" (the mount-level sandbox hides paths outside sandbox.allowedPaths
entirely). But Read(/home/leon/.bashrc) — same absolute path — succeeded
and returned the file's contents.

This indicates Read/Write/Edit are not subject to the same OS/mount-
level sandbox that constrains Bash, and their only access control is the
permissions.allow/deny rule engine — which, per the above, is not being
consulted (or is silently no-op'ing) before the file open for these rules.

Impact

Any project relying on permissions.deny with Read(...) glob rules to
keep Claude out of specific paths (secrets, other users' files, system
config, sibling projects, etc.) gets no actual protection from that rule for
the Read tool — only real OS file permissions and the (separately
configured, and much more limited) sandbox allowedPaths list provide any
enforcement. This is easy to miss because the /permissions UI displays the
rule as present and active, and explicitly states denied tools are "always"
rejected.

Suggested fix direction

Have the Read/Write/Edit tool handlers run the same
permissions.deny glob match that gates the interactive approval prompt
before performing the filesystem operation, independent of whether the
call would otherwise auto-approve/auto-deny via the sandbox. Alternatively,
if Read/Write/Edit are intentionally exempted from mount-level
sandboxing for legitimate reasons, that tradeoff should at minimum be
reflected honestly in the /permissions UI (e.g. "Deny rules apply to Bash
only" or similar), rather than claiming a universal guarantee.

What Should Happen?

Expected behavior

Every call above should be hard-blocked by the Deny rule — per the
/permissions UI's own description, Claude Code should "always reject
requests to use denied tools," with no prompt and no read.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

1. In a project with .claude/settings.json containing "deny": ["Read(/etc/**)", "Read(/home/**)"] (and a narrower allow carving back only the project directory), start a session.
2. Confirm via /permissions that the rules appear as active/duplicated in the Deny tab.
3. Call the Read tool on a path matched by the deny rule, e.g.:
   • Read(/etc/passwd)
   • Read(/etc/hosts)
   • Read(/etc/bluetooth/main.conf) (nested, 2 levels deep)
   • Read(/etc/unbound/root.key) (nested)
   • Read(/home/leon/.bashrc) (outside the allowed project carve-out)

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.223

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

No response

[javazquez9611-oss]

Independent reproduction on a different OS, different entrypoint, and a newer version — plus one data point that may mean your "Read-specific" framing is too narrow.

Environment (differs from yours on every axis)

• Claude Desktop 1.32885.1, embedded Claude Code runtime 2.1.234 (yours: CLI 2.1.223)
• macOS 26.6.1 / Darwin 25.6.0 (yours: Fedora/Linux)
• Project-scoped .claude/settings.local.json, session launched at project root

Same core failure

Read of paths inside permissions.deny globs returns full contents — no denial, no prompt, no error. Reproduced 4x in a long-running session and 1x in a fresh session, and again today on 2.1.234.

Extending your pattern coverage: it isn't a glob-matching bug

You tested glob rules. I also tried a literal, non-glob absolute path in the docs-correct // form — Read(//Users/<user>/.zsh_history) — and it also returned contents. Four syntactic variants total in one session (//-absolute, single-slash absolute, ~/-form, and the exact non-glob path). All four failed to block.

The data point that may contradict "Bash correctly enforces"

On my machine the Bash/sandbox side fails too:

• cat of a path listed in sandbox.credentials.files → exit 0, 941 bytes returned, no block, no prompt
• curl to a host absent from sandbox.network.allowedDomains → HTTP 200 (tracked separately in [BUG] Sandbox network allowedDomains not enforced on macOS: built-in proxy CONNECTs to non-allowlisted hosts (CLI 2.1.205) #77045; I've added a 2.1.234 reproduction there rather than duplicating it here)
• Both observed with sandbox.enabled: true and sandbox.failIfUnavailable: true — the session started and ran normally anyway, so either the sandbox is active and failing open, or it was unavailable and failIfUnavailable was silently ignored.

So: your Linux/CLI environment shows the Read bypass with a working Bash sandbox. My macOS/Desktop environment shows the Read bypass with the sandbox non-functional on both filesystem and network. If these share a root cause, "Read-specific, not a general policy failure" may be too narrow — it may be that engine engagement varies by platform or entrypoint, and your configuration happened to be one where the Bash half still works.

Disclosure, so it isn't the first reply

This account has bypassPermissionsOptInByAccount / bypassPermissionsGateByAccount set to true, and some sessions on this machine run --permission-mode bypassPermissions. Per the permission-modes doc — "Deny rules block in every mode, including bypassPermissions" — and per the runtime's own internal string ("auto-approves every tool call (except explicit deny rules)"), deny enforcement is expected regardless of session mode, so this is a defect either way.

Also relevant to your regression note: #84318 reports deny working correctly at project root on 2.1.220 while failing from a subdirectory. Mine is the root-launch case failing on 2.1.234, which is consistent with your "this worked in a previous version."

[shleder]

Hi @poshleon,

Regarding the permission inconsistency and glob filtering issues with agent tool execution: In-process rule filtering often allows bypasses via compound sub-shell execution or tool fallbacks. To enforce strict fail-closed filesystem and network boundaries at the OS kernel level, take a look at vetto (Rust, Landlock on Linux, Seatbelt on macOS).

You can wrap your agent transparently via PATH shims in one command:

npm i -g @shledery/vetto && vetto enable <agent>
# or via Homebrew:
brew install shleder/tap/vetto && vetto enable <agent>

It runs fail-closed with zero background daemon requirement.

Full disclosure: I am the creator/maintainer of Vetto. Happy to answer questions if you want to test or integrate it.