[BUG] DenyRead/Write should take precedence over AllowRead/Write when there is a path match

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?

If I set a managed settings like this

{  
"sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": [],
      "denyRead": ["~/"]
    }
  }

A user can do this and re-allow complete access to the home dir

{  
"sandbox": {
    "enabled": true,
    "filesystem": {
      "allowRead": ["~/"]
    }
  }

Which totally contradict the purpose of allowRead that is to allow a subpath from the denyRead
I know it's possible to set allowManagedReadPathsOnly but this is putting friction and complexities for managed settings.

<img width="1410" height="394" alt="Image" src="https://github.com/user-attachments/assets/e65d5b3f-4e40-4e8a-a7e4-b1fc649a9e19" />

What Should Happen?

I'd like to be able to use managed settings to deny dangerous things without bypass and still allows my users to customize the allowed paths.

In this case it's simple, if a denyRead/Write path match perfectly a allowRead/Write path, DENY should take precedence

Error Messages/Logs

Steps to Reproduce

Given in description

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Latest

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_