Windows: Remove-Item guard blocks any command containing a path with a space

Summary

On Windows, the built-in Remove-Item protection blocks a command whenever the command text contains any Windows path with a space in it, regardless of what is actually being deleted. The guard appears to split the path at the first space and treat the leading fragment as a protected drive root.

The error names a fragment, not a real path:

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

Note '"C:\Program' — the leading quote is included and the path is truncated at the space.

Reproduction

Each of these is a single PowerShell tool call. The file being deleted is always a throwaway file in %TEMP%.

1. Baseline — passes

$t = "$env:TEMP\probe.txt"
"x" | Set-Content $t
Remove-Item $t -ErrorAction SilentlyContinue

2. Path without a space — passes

$t = "$env:TEMP\probe.txt"
"x" | Set-Content $t
Remove-Item $t -ErrorAction SilentlyContinue
$other = "C:\Python314\python.exe"

3. Path with a space — BLOCKED

$t = "$env:TEMP\probe.txt"
"x" | Set-Content $t
Remove-Item $t -ErrorAction SilentlyContinue
& "C:\Program Files\Git\bin\bash.exe" -c "echo hello"

→ Remove-Item on system path '"C:\Program' is blocked.

4. Ordinary user directory with a space — BLOCKED

$t = "$env:TEMP\probe.txt"
"x" | Set-Content $t
Remove-Item $t -ErrorAction SilentlyContinue
$other = "C:\AI Projects\README.md"

→ Remove-Item on system path '"C:\AI' is blocked.

5. Reversed order — still BLOCKED

Putting the spaced path before Remove-Item blocks identically, so this is not proximity or line based.

Expected vs actual

Expected: the guard inspects the argument actually passed to Remove-Item and blocks only if that resolves to a protected location.

Actual: the guard scans the whole command text for two independent things — the verb Remove-Item, and anything shaped like a path — and blocks on the pair. The deletion target is never consulted.

Impact

Case 4 is the important one. C:\AI Projects is an ordinary user working directory, not a system path. Any project whose folder name contains a space makes every cleanup command unrunnable, because merely mentioning the project path anywhere in the command triggers the guard.

Two very common Windows paths hit this by construction:

• C:\Program Files\... → reported as C:\Program
• C:\Users\<name>\My Documents\... and similar

The practical effect is worse than an inconvenience. Deleting a stale artifact before re-running a check is often what makes the check valid. When that step is blocked, the natural workaround is to drop the cleanup — and the check then silently reuses the old artifact and can no longer fail.

Environment

• Claude Code, desktop app (Code tab)
• Windows 11 Pro 10.0.22631
• PowerShell 7.6.5
• Model: Opus 4.5

The message string protected from removal is present in the bundled claude.exe shipped under claude_agent_sdk/_bundled/, so this is product behaviour rather than a user hook. Confirmed no user-defined hook produces it: the string does not appear in any hook file in the user or project config.

Suggested fix

Resolve the argument(s) actually passed to Remove-Item and compare those against the protected list, rather than pattern-matching path-shaped substrings across the whole command. If a text-level check must be kept as a cheap pre-filter, at minimum it should not truncate at whitespace inside a quoted path, and should not treat a two-segment fragment like C:\AI as a drive root.