PowerShell tool: destructive-path guard mis-extracts an unrelated quoted token as the delete target (false-positive blocks)

Additional case: the guard also fires on git rm (not just Remove-Item), and can extract an empty path

Fresh instance today on Windows 11 / PowerShell tool (pwsh 7), while extracting a subdirectory into its own repo. Notable for two reasons: (1) the command was git rm, not Remove-Item — so the scanner keys on the bare rm token, widening the blast radius to git subcommands; and (2) git rm --cached is non-destructive — it only unstages from the index, it never touches the working tree.

Command (interactive — only unstages two dirs from the git index, deletes no files):

git -C $dir rm -r --cached --quiet uploads _dev

Blocked with:

Remove-Item on system path ''/'' is blocked. This path is protected from removal.

The extracted "path" was empty ('') — the scanner saw the rm subcommand, couldn't parse a target past the -r --cached --quiet flags and the two trailing args, and fell back to an empty// path → blocked.

Same session, the unresolved-variable variant also fired (consistent with the note in the original report):

[System.IO.File]::Delete($idx)   →   Remove-Item on system path ''/'' is blocked. ...

Workarounds that parse cleanly: give git rm an explicit single quoted path after -- (git rm -r --cached -- "relative/path"), or use a literal path with [System.IO.File]::Delete('C:\...\literal'). The trip-wires are the multi-flag/multi-arg form and unresolved-variable targets.

Net: the guard should (a) not key on a bare rm token inside git rm — especially git rm --cached, which deletes nothing — and (b) never fall back to / or '' when it can't confidently extract a target; an unparseable target shouldn't block on a guessed root path.

Also reproduces on Windows PowerShell 5.1 (powershell.exe), and — notably — fires on commands that contain no Remove-Item, rm, or git rm at all.

Two blocks today, neither command containing any delete/destructive cmdlet (only process enumeration, or file create/copy):

1. Read-only, double-quoted regex — a command enumerating processes (Get-CimInstance Win32_Process) and pulling a UUID from each command line with -match "(?:--resume|-r)\s+$uuid":

``
Remove-Item on system path '\s+$uuid' is blocked. This path is protected from removal.
``

1. File create/copy (New-Item + Copy-Item + Set-Content — no delete), reusing the same \s+ regex literal in single quotes:

``
Remove-Item on system path '\s+' is blocked. This path is protected from removal.
``

So the \s+-as-target extraction (case 2 of the original report) does not require an actual Remove-Item/rm in the command — the regex literal alone trips the "Remove-Item on system path" rule. (The only rm substring present was inside Format-Table, which was also present in a command that passed, so that substring isn't the trigger on its own.)

Intermittency, sharpened: the identical single-quoted literal '(?:--resume|-r)\s+([0-9a-fA-F-]{36})' passed in one read-only command and was blocked in another that additionally did Copy-Item/Set-Content. Consistent with the "depends on command shape" note — here the co-occurring file-write cmdlets seem to matter.

Workaround that avoids it: drop the regex and tokenize with .NET — "$s".Split([char[]]@(' ', [char]9), [System.StringSplitOptions]::RemoveEmptyEntries) — no \s+, no block.

Environment: Claude Code 2.1.210 (PowerShell tool, Windows PowerShell 5.1 / powershell.exe), Windows 11.

Likely the same root cause as #73524.

Pointer, because this thread is where the missing minimal repro was called out ("minimal synthetic repros ... did not trip it").

Here is a deterministic one on 2.1.229, Windows 11, PowerShell tool. The two commands differ by a single echoed string literal.

Control — runs:

Set-Content -Path "C:\Users\mcamp\AppData\Local\claude-guard-probe.txt" -Value "x"
Remove-Item "C:\Users\mcamp\AppData\Local\claude-guard-probe.txt" -Force
"F-A control ran"

Variant — add one line, denied every time:

Set-Content -Path "C:\Users\mcamp\AppData\Local\claude-guard-probe.txt" -Value "x"
"A:"
Remove-Item "C:\Users\mcamp\AppData\Local\claude-guard-probe.txt" -Force
"F-B variant ran"

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

Two notes on why this one reproduces where the earlier attempts didn't:

• A bare drive letter, not a slash-string. The root-path predicate accepts ^[A-Za-z]:\/?$ as well as the / forms discussed above, so "A:" qualifies while /synthesize and friends depend on other branches. It is also language-independent, unlike the Spanish del collision reported on #81378.
• The shape requirement is real. The deny only happens on the fallback string-splitter, which runs when the AST parse fails — the code is inside an if(!i.valid){...}. Two statements parse fine and pass, which is exactly the intermittency described here. The four-line form above is enough to fail the parse.

The full write-up, with the verbatim 2.1.229 code — the two script-global variables and the if(K&&j!==void 0)return pat(j) line that combines them across unrelated statements — is on #81378: https://github.com/anthropics/claude-code/issues/81378#issuecomment-5330356143

That comment also shows Remove-Item Q:\Windows -Recurse -Force still blocking on 2.1.229, i.e. the statement-scoped inner loop catches genuine attempts and the cross-statement branch can be removed without weakening the guard.