Windows 8.3 short-name in %TEMP% triggers false-positive "suspicious Windows path pattern" approval prompts on the session scratchpad

Environment

• Claude Code v2.1.218
• Windows 11, Git-Bash shell
• %TEMP% = C:\Users\JOONAT~1.HAM\AppData\Local\Temp (8.3 short-name form; %USERPROFILE% is the long C:\Users\joonatan.hamalainen)

Summary

When %TEMP% resolves to an 8.3 short-name path — common on accounts whose Windows username is longer than 8 characters or contains a dot/space — the per-session scratchpad path Claude Code generates (%TEMP%\claude\<project>\<session>\scratchpad) contains a ~1 segment. Tool calls that reference this path (both Write/Edit and Bash) are gated by a heuristic that reports "contains a suspicious Windows path pattern that requires manual approval," evidently treating the ~ as possible path traversal/obfuscation.

The result: the user is prompted to approve nearly every operation on the scratchpad — a directory the harness itself directs the model to use — many times per session.

Reproduction

1. On a Windows account whose %TEMP% is a short-name path (echo %TEMP% shows ...~1...), start Claude Code.
2. Have the session write to or read from any file under its scratchpad directory.
3. Observe a "suspicious Windows path pattern" approval prompt on each such operation.

Impact

• Constant permission friction on the harness's own mandated temp location.
• Not suppressible by permissions.allow, permissions.additionalDirectories, or permissions.defaultMode: acceptEdits — it is a separate heuristic, not the standard tool-permission gate. This also makes it hard to diagnose, since none of the usual permission levers affect it.
• The persist option offered in the prompt ("always allow access to scratchpad from this project") does not reliably help, since the scratchpad path carries a per-session id.

Expected

A legitimate Windows 8.3 short name is a normal OS artifact, not a suspicious pattern. The heuristic should not fire on it — at minimum, not for the harness's own scratchpad subtree.

Suggested fix (any of)

1. Canonicalize the temp/scratchpad base at session start via GetLongPathName (or derive it from %LOCALAPPDATA%) so the generated scratchpad path contains no ~1.
2. Exempt the session's own scratchpad directory from the suspicious-path heuristic — it is a trusted, harness-created location.
3. Recognize the NAME~N 8.3 short-name pattern specifically and treat it as benign.

Workaround

Point TEMP/TMP at the long-form of the same directory (via setx, or a shell profile that sets $env:TEMP/$env:TMP) and relaunch. This removes the ~1 from the scratchpad path and the prompts stop.