Feature request: disable suspiciousPathGuard for bypassPermissions users

Feature Request — disableSuspiciousPathGuard flag (or per-path opt-out)

Target repository: anthropics/claude-code
Date drafted: 2026-04-30

Summary

Claude Code's "suspicious Windows path pattern" guard fires above defaultMode: bypassPermissions, requiring manual approval on every Read/Write/Edit/Bash tool call whose target path contains characters Claude Code's internal heuristic treats as suspicious (e.g., the tilde-digit form from 8.3 short-form paths such as USERNA~1 or MYDRIV~1, certain Unicode sequences, parentheses, drive letters in unusual contexts).

For users who have already opted into bypassPermissions and whose Windows username or path layout produces 8.3 short-form paths, this guard creates a hard wall: every single tool call prompts, defeating the purpose of bypass mode entirely. The user reports 100+ prompts per day on this exact pattern.

Reproduction

1. Windows username with a parenthesis or other shell-fragile character (the parenthesis breaks cmd.exe and PowerShell scheduled-task argument parsing, so the user must use the 8.3 short form everywhere).
2. User configures ~/.claude/settings.json with permissions.defaultMode: "bypassPermissions".
3. User instructs the agent to use 8.3 short-form (C:\Users\USERNA~1\...) for every path operation to avoid the underlying shell-parsing bug.
4. Result: every Read/Write/Edit/Bash that includes the 8.3 path prompts with "contains a suspicious Windows path pattern that requires manual approval."
5. The "Always allow" action does not generalize across path strings — each new file produces a fresh prompt.

Impact

• bypassPermissions is rendered useless on this machine.
• Workarounds the user must adopt: NTFS junction (mklink /J C:\alias C:\Users\USERNA~1\...) or subst to expose a clean alias path. Both are OS-level workarounds the user shouldn't need.
• Cumulative cost: hours per week lost to manual approval clicks. The user has flagged this as a critical workflow blocker.

Requested change

One of the following, in order of preference:

1. permissions.disableSuspiciousPathGuard: true — top-level setting that disables the guard entirely for users who have opted into bypassPermissions.
2. permissions.suspiciousPathAllowlist: ["C:\\Users\\USERNA~1\\**"] — pattern allowlist that suppresses the guard for matching paths.
3. Resolve symlinks/junctions before guard check — would automatically allow users to escape via OS-level aliasing without requiring a settings change.
4. Document the guard's exact triggers — at minimum, publish what character sequences activate it so users can avoid them in their own workflows.

Workaround currently being used

mklink /J C:\alias "C:\Users\USERNA~1\MYDRIV~1\Project" — junction at C:\alias so all subsequent operations reference the clean alias. Verified to bypass the guard if Claude Code resolves the surface path string rather than the canonical realpath. Path operations through the junction succeed without prompting; identical operations through the original 8.3 path prompt every time.

Why bypass-mode users want this

Users who have already taken the explicit step to enable bypassPermissions have made a considered tradeoff: faster workflow for known-trusted environments. A safety guard that overrides their explicit setting for paths their own filesystem produces without an opt-out flag is paternalistic. It should be possible to disable.

---

Filing instructions: submit at https://github.com/anthropics/claude-code/issues using gh issue create -R anthropics/claude-code -t "Feature: disable suspiciousPathGuard for bypassPermissions users" -F C:\codex\tmp\claude-code-feature-request-suspicious-path-guard.md. Or paste the body manually into a new issue on the repo.