Path-pattern scanner false-positives on Windows 8.3 short names (e.g. ALICEM~1), bypassing user allow-rules — affects users with non-ASCII chars in their Windows username

Summary

Same scanner family as #54856, but a different trigger on Windows: the path-pattern security scanner fires on Windows 8.3 short filenames (e.g. ALICEM~1) and forces manual approval even when a matching allow-rule is configured. The scanner runs at a layer above the permission/allow-list system, so users cannot pre-approve these paths.

This affects any user whose Windows username contains a non-ASCII character (ö, ä, å, ü, é, etc.). Windows generates an 8.3 short name for such folders (e.g. AliceMüller → ALICEM~1), and various Windows APIs return paths in that form. The scanner then treats the ~1 substring as a "short name" pattern that requires manual verification.

The most visible symptom: Claude Code's own internal tool-output files live under %LOCALAPPDATA%\Temp\claude\..., and the scanner blocks Claude from reading them on every single tool invocation.

Symptom

Permission prompt on every read of Claude's own task-output files:

Allow Claude to read bpdleqw3p.output?
C:\Users\ALICEM~1\AppData\Local\Temp\claude\C--projects-myrepo\ff1508f5-...\tasks\bpdleqw3p.output

Path contains suspicious Windows-specific patterns (alternate data streams,
short names, long path prefixes, or three or more consecutive dots) that
require manual verification

Environment

• Claude Code: 2.1.136
• Windows 11 Pro 10.0.26100
• Windows username contains a non-ASCII letter (in this repro: ü; same effect with ö, ä, å, é, etc.)
• Windows surfaces the short name (ALICEM~1) to processes that don't explicitly request the long form via GetLongPathNameW

Allow-rule that should cover this but doesn't

~/.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Read(//c/Users/*/AppData/Local/Temp/claude/**)"
    ]
  }
}

Format is the POSIX-normalized form documented at https://code.claude.com/docs/en/permissions ("On Windows, paths are normalized to POSIX form before matching. C:\Users\alice becomes /c/Users/alice"). The rule is written correctly, but the scanner runs above the permission layer (see #54856) and the prompt fires anyway.

Expected vs Actual

• Expected: When the user has an explicit Read(...) allow-rule that matches the path (in either long-name or short-name form), the scanner should defer to that rule and not force a manual prompt.
• Actual: Scanner fires on every read; allow-rule has no effect; "Allow once" must be clicked each time.

Why this matters

Unlike the macOS .-in-username case in #54856, this isn't only the user's own files — it's Claude Code's own internal output files. The directory path is created by Claude Code itself under %TEMP%, and Claude's own subagent/task machinery has to read those files back. So users with non-ASCII usernames are forced to manually approve Claude reading its own internal state, which fundamentally breaks the auto-permission model.

Workarounds (none clean)

1. Move %TEMP% to an ASCII-only path (e.g. C:\Temp) — global change with installer/Windows Update side effects, not recommended.
2. Disable 8.3 name generation on C: via fsutil 8dot3name set C: 1 — system-wide, requires admin, can break legacy apps.
3. Rename the Windows user account — high cost.
4. Click "Allow once" forever.

Suggested fix

Either:

• Have the scanner consult the resolved allow-rules and skip the warning when an exact Read/Write/Bash rule matches the path (in either short-name or long-name form), or
• Resolve short names to long names before running the scanner (GetLongPathNameW), since ~1 in a Windows path is almost always a benign 8.3 alias rather than a real attack vector.

Related

• #54856 — same scanner, different trigger (macOS . in username), same root cause (allow-rules bypassed)