Read/Grep/Edit denied for src/main/java paths with no matching permission/sandbox rule anywhere in config

Description

Read, Grep, and Edit tool calls are denied for files under a specific subpath (src/main/java/** of a Maven module) with the message:

File is in a directory that is denied by your permission settings.

Sibling paths in the exact same module (pom.xml, src/main/resources/**) are readable without issue — only src/main/java/** is blocked. This reproduces consistently across multiple fresh sessions and after fully quitting and relaunching the Claude Code app (not just restarting the terminal).

Environment

• Claude Code version: 2.1.218
• OS: Windows 11 (Windows 11 Pro 10.0.26200)
• Shell: Git Bash (MINGW64) / PowerShell 5.1
• Working directory: multi-root workspace, project root D:\dev, target files under D:\dev\workspace_backend\<module>\src\main\java\**

Steps to reproduce

1. Open a project at D:\dev containing a nested directory workspace_backend\<maven-module>\src\main\java\...\SomeFile.java.
2. Call Read (or Grep/Edit) on that file.
3. Observe: File is in a directory that is denied by your permission settings.
4. Call Read on a sibling file in the same module outside src/main/java (e.g. pom.xml, or a file under src/main/resources/**) — succeeds normally.

What we checked (all clean — no rule found anywhere)

• D:\dev\.claude\settings.json and settings.local.json — no sandbox key, no deny rule matching this path.
• workspace_backend\.claude\settings.json and settings.local.json — explicitly contain Read, Read(**/src/main/java/**), Edit(**/src/main/java/**) in permissions.allow; deny only lists Edit(douzone-comet-webapp-boot/**), unrelated.
• No managed-settings.json present at any enterprise policy path.
• ~/.claude.json project entries for both D:/dev and D:/dev/workspace_backend — allowedTools: [], no per-project deny cache, hasTrustDialogAccepted: true.
• No relevant sandbox/SANDBOX/CLAUDE_CODE_* environment variables set beyond standard session identifiers.
• Confirmed not a path-length/MAX_PATH issue (paths are ~110-140 chars).
• Confirmed not the backslash/case-variant permission-matching bug fixed in 2.1.162 (changelog) — already long since included in 2.1.218.

Attempted fixes that did NOT resolve it

1. Removed a previously-present (unrelated-looking) sandbox.filesystem.allowRead block from settings.local.json — no change.
2. Restarted the terminal / started a fresh session (new CLAUDE_CODE_SESSION_ID) — no change.
3. Fully quit and relaunched the Claude Code app (not just the terminal) — no change.

The denial is precisely and consistently scoped to src/main/java/** under this workspace, while every other sibling path in the same directory tree is accessible, and no discoverable configuration anywhere in the reachable settings hierarchy (project, nested project, user, legacy global cache, env) produces this rule. This suggests either an internal/hardcoded path-matching bug (e.g. something about the src/main/java segment or its depth/nesting) or a sandbox boundary computed at session start from a source we could not locate/inspect from within the session.

Happy to provide additional repro details if needed.