[BUG] Permission glob patterns don't match Windows 8.3 short name paths (JOHNSM~1 vs JohnSmith)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, permission allow patterns fail to match file paths when Windows resolves the username to an 8.3 short name (e.g. JOHNSM~1 instead of JohnSmith). Background tasks and subagents generate paths using the short name form, so allow rules never match for temp directory files.

Controlled test with the same file, same session, same allow rules:

| Path format | Prompted? |
|---|---|
| C:\Users\JohnSmith\AppData\Local\Temp\claude\... | No |
| C:/Users/JohnSmith/AppData/Local/Temp/claude/... | No |
| C:\Users\JOHNSM~1\AppData\Local\Temp\claude\... | Yes |

The global allow rule Read(//c/Users/JohnSmith/**) catches the long-name paths but not the short-name paths. Adding explicit short-name patterns in multiple formats also fails:

"allow": [
    "Read(//c/Users/JOHNSM~1/AppData/Local/Temp/claude/c--project-dir/**)",
    "Read(C:\Users\JOHNSM~1\AppData\Local\Temp\claude\c--project-dir\**)",
    "Read(//c/Users/*/AppData/Local/Temp/claude/**)",
    "Read(**/AppData/Local/Temp/claude/**)"
]

None of these match a JOHNSM~1 path. The * wildcard and ** prefix patterns also fail to match.

The directory is also listed in additionalDirectories (both short and long name forms) with no effect on prompts.

What Should Happen?

The permission matcher should resolve Windows 8.3 short names to long names (or vice versa) before glob matching, so that JOHNSM~1 paths match patterns containing JohnSmith or *.

Error Messages/Logs

Allow reading from C:\Users\JOHNSM~1\AppData\Local\Temp\claude\c--project-dir\76c0995d-...\tasks\b2nvecpt7.output?

Allow grep in C:\Users\JOHNSM~1\AppData\Local\Temp\claude\c--project-dir\76c0995d-...\tasks\b2nvecpt7.output?

Steps to Reproduce

1. Use Windows with a username long enough to have an 8.3 short name (6+ chars)
2. Add global allow: Read(//c/Users/JohnSmith/**)
3. Find a file in the Claude temp directory: C:\Users\JOHNSM~1\AppData\Local\Temp\claude\...
4. Ask Claude to read that file using the long-name path: C:\Users\JohnSmith\AppData\Local\Temp\... - no prompt
5. Ask Claude to read the same file using the short-name path: C:\Users\JOHNSM~1\AppData\Local\Temp\... - prompted

In practice, background tasks and subagents generate the short-name paths, so users are prompted for every task output read despite having allow rules.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.108 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

This is related to but distinct from #29574 (WSL path normalization). That issue covers forward-slash vs backslash matching on WSL. This issue is specific to native Windows where the glob matching itself works for long-name paths, but 8.3 short name resolution breaks all pattern matching regardless of format.

The ~ character in the short name may be relevant - it could be interpreted as a glob special character by the pattern matcher, which would explain why even literal JOHNSM~1 patterns and wildcard * patterns fail to match.