Read tool ignores permissions.deny Read(/Users/**) rules in managed-settings.json and user settings.json

Environment: Claude Code, VS Code native extension. Policy configured via both an MDM-deployed managed-settings.json (/Library/Application Support/ClaudeCode/managed-settings.json, symlinked to a project file) and the user's own ~/.claude/settings.json, both containing permissions.deny entries including Read(/Users) and Read(/Users/**) (and matching Write/Edit entries).

Repro steps:

1. With the above deny rules active, ask the model to use the Read tool on any file under the user's home directory that is not part of an explicit allow carve-out (e.g. a dotfile like ~/.zshrc).
2. Observe the tool call result.

Expected: The call is denied/blocked per the configured Read(/Users/**) deny rule, consistent with how the underlying OS-level sandbox handles the same path.

Actual: The Read tool call succeeds and returns the full file contents, bypassing the deny rule entirely. This was verified twice: once under the managed-settings-only configuration, and again after the user added the identical deny rule to their own ~/.claude/settings.json and reloaded context — the second attempt still succeeded, unchanged.

Notable contrast: Running the OS-level equivalent via the Bash tool (e.g. ls on a path under the same denied tree) is correctly blocked ("Operation not permitted"), showing the sandbox's own filesystem enforcement works. The gap appears specific to the Read tool's permission-check path not consulting/enforcing the configured permissions.deny rules for Read.

Impact: Any file under a user's home directory containing secrets (shell rc files with exported credentials, config files, etc.) can be read by the model regardless of an explicit, correctly-formed policy denying it. This defeats a core safety control, especially in managed/enterprise deployments that rely on managed-settings.json for compliance-driven restrictions.

No secret values or file contents are included in this report.