Built-in command-safety analyzer false-positives on quoted Windows paths with spaces

Bug: built-in command-safety analyzer false-positives on quoted Windows paths with spaces

Component: Claude Code CLI — built-in PowerShell/Bash tool command-safety analyzer
(the layer that emits … is blocked. This path is protected from removal. — NOT a user PreToolUse hook)
Version: Claude Code 2.1.150
OS / shell: Windows 11 (10.0.26200), Windows PowerShell 5.1 (powershell.exe)
Severity: Low-functionality / annoyance (blocks legitimate commands; safe workaround exists)

Summary

The built-in safety analyzer that protects against deleting system paths appears to tokenize the
command on whitespace without honoring quotes, and to flag a protected-root substring anywhere in
the command rather than binding the deletion verb to its actual argument.

As a result, a command that (a) contains a deletion verb (Remove-Item) targeting a safe path, and
(b) separately references a quoted Windows path that contains a space under a protected root —
most commonly the Chrome executable at "C:\Program Files\Google\Chrome\Application\chrome.exe" — is
blocked, with the analyzer reporting the pre-space fragment C:\Program as the delete target:

Remove-Item on system path '"C:\Program' is blocked. This path is protected from removal.

Note the captured target is "C:\Program — the quote char plus the substring up to the first space —
which is neither the real Remove-Item argument nor a real path.

Reproduction

Run this single PowerShell tool command (the Remove-Item targets only a temp path; the
C:\Program Files\... string is just an executable reference):

$chrome = "C:\Program Files\Google\Chrome\Application\chrome.exe"
Remove-Item -Force "$env:TEMP\does_not_exist" -ErrorAction SilentlyContinue
& $chrome --version

Expected

Command runs (deletes nothing harmful; prints the Chrome version).

Actual

Blocked before execution with:
Remove-Item on system path '"C:\Program' is blocked. This path is protected from removal.

Root-cause hypothesis

1. The protected-path check scans the whole command string for protected roots, instead of

parsing the deletion cmdlet and resolving its argument.

1. Tokenization splits on whitespace without quote-awareness, so the quoted path

"C:\Program Files\..." is split into "C:\Program + Files\..., and the first piece matches a
protected-root prefix (C:\Program ⊂ C:\Program Files).

1. The deletion verb and the matched fragment are correlated by proximity/co-occurrence, not by actual

argument binding — so a Remove-Item of a different, safe path is attributed the wrong target.

Impact

Blocks routine commands that invoke an executable under C:\Program Files (Chrome, etc.) in the same
command as any cleanup/delete — e.g. headless-Chrome screenshot + temp-folder cleanup. Forces splitting
commands or rewriting paths.

Workaround (verified)

Avoid the literal C:\Program Files substring in any command that also deletes:

• Use the env var: "$env:ProgramFiles\Google\Chrome\Application\chrome.exe" (no C:\Program Files

literal → not flagged). Verified to run with a Remove-Item in the same command.

• Or (Get-Command chrome).Source.
• Or split the deletion into its own separate command.

Suggested fix

• Make the protected-path check quote-aware (treat "C:\Program Files\..." as one token).
• Bind the deletion to its real argument(s) before evaluating protected roots, rather than matching

any protected-prefix substring elsewhere in the command.

• Only flag when the resolved deletion target is (or is at/above) a protected root — not when a

protected path merely appears as an unrelated executable reference.

Note

This is distinct from any user-defined PreToolUse hook. Verified locally: a custom catastrophe-guard
hook returns ALLOW for the same command; the block originates from the built-in analyzer.