[BUG] Write deny rules behave as ask — file creation is prompted instead of automatically blocked; also affects organization-managed settings

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?

On Windows, Write(...) entries in the deny list of settings.json are not enforced as denials. Instead of automatically blocking the action, Claude Code falls back to showing a permission prompt — identical to the behavior of an ask rule. The user can then approve the write, defeating the deny rule entirely.

This affects both project-level and organization-managed settings, which is a serious security and confidentiality concern: administrators deploying organization-managed settings expect deny rules to act as hard blocks that end users cannot override.

Actual Behavior

A permission prompt is shown, and if the user approves it, the file is created. The deny rule has no effect: it neither blocks the action automatically nor prevents the user from overriding it. This was reproduced with all of the following rule variants — none triggered an automatic block:

  "Write(C:/**)"
  "Write(C:\\Users\\<USERNAME>\\Folder A\\**)"
  "Write(**/Folder A/Folder B/**)"
  "Write(C:/Users/<USERNAME>/Folder A/Folder B/**)"

The Write(C:/**) case is the most significant: it is a catch-all for the entire C: drive and should match any Windows path, yet it is silently downgraded to a prompt.

Security Impact

This bug is especially serious at the organization-managed settings level. Organization-managed settings are intended to give administrators hard enforcement guarantees — paths listed under deny should be inaccessible to Claude Code regardless of what the end user does. Because the deny rule is silently downgraded to a prompt, an end user can approve writes to any path the administrator intended to protect (e.g. SharePoint/OneDrive sync folders containing confidential documents). This breaks the security boundary that organization-managed settings are designed to provide.

What Should Happen?

The Write tool call should be automatically blocked with no prompt. deny rules are documented as hard blocks — the user should never be asked. The action must not be completable regardless of user response.

Error Messages/Logs

Steps to Reproduce

1. Add the following deny rule to .claude/settings.json at project level or to the organization-managed settings file:

  {
    "permissions": {
      "deny": [
        "Write(C:/**)"
      ]
    }
  }

1. In a Claude Code session, ask Claude to create a file anywhere on the C: drive outside the project directory, e.g.:

Create a file hello.txt containing "hello" at C:\Users\<username>\Desktop\hello.txt

1. Observe that a permission prompt appears, allowing the user to approve or deny the action manually.

NOTE: the same applies with more specifics patterns like "**/some folder/**". This applies on windows terminal, powershell, and pycharm terminal.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.114

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

The https://docs.anthropic.com/en/docs/claude-code/settings#permission-rules that on Windows, paths are normalized to POSIX form before glob matching. Whether or not this normalization is occurring, the outcome is identical: deny rules for Write on Windows paths are never enforced as blocks. The Write(C:/**) case — which should match any path on the C: drive regardless of normalization strategy — confirms the issue is not a glob syntax problem but a failure in deny rule enforcement itself.

Related issues:
[#43667](https://github.com/anthropics/claude-code/issues/43667 )
#44091
#46461

NOTE: I didn't check but i suspect the same applies to the Edit command with the same security issues