PowerShell safety guard: Spanish word "del" inside a quoted commit message is treated as Remove-Item, then blocks on a quote-split path fragment

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 29, 2026

Bug: PowerShell safety guard treats the Spanish word "del" inside a quoted commit message as a Remove-Item alias, then blocks on a quote-split path fragment

Summary

The built-in protected-path guard for the PowerShell tool (the one that emits Remove-Item on system path 'X' is blocked. This path is protected from removal.) has a failure mode where a command containing no deletion at all is blocked:

  1. The deletion-alias scan matches the token del inside a quoted string literal — here, the Spanish preposition/contraction "del" ("de + el", one of the most common words in Spanish) inside a git commit -m "..." message.
  2. Having "found" a Remove-Item, the target extraction then splits the command by whitespace without respecting quotes, grabs the fragment "C:\IA from the quoted repo path "C:\IA Local\Produccion de Video" (note the blocked "path" literally includes the leading quote character), and judges it a protected system path.

Result: a plain git commit is denied before execution.

Environment

  • Claude Code 2.1.220, native Windows build (npm @anthropic-ai/claude-code, claude.exe)
  • Windows 11 Home 10.0.26200, native PowerShell tool (pwsh 7)
  • Permission mode: bypassPermissions (guard fires even there)
  • No user hook involved — confirmed: the message string exists in no settings file or hook on the machine; it is present (compiled) inside claude.exe itself, next to the strings safetyCheck / Removal targets a protected system path.

Deterministic repro (verified 2026-08-29)

In any git repo under a path with spaces (here C:\IA Local\Produccion de Video), via the PowerShell tool:

git -C "C:\IA Local\Produccion de Video" commit -m "prueba del guard"

Actual: blocked before execution with

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

Control cases, all run the same day on the same machine:

| Variant | Result |
|---|---|
| Same command, message without "del" (-m "prueba guard bug tokenizado") | runs (git executes) |
| Same command with "del", via the Bash tool | runs (guard only parses the PowerShell tool) |
| Same quoted -C path, commit -F msg.txt where the file contains "del" | runs |
| git init / add / push with the same quoted path | run (no free text → no false alias) |

The last row is what makes this so misleading in practice: only commit carries natural-language text, so the failure correlates perfectly with "commit" and looks like a commit hook bug. We spent several sessions blaming (and working around) our own PreToolUse hooks before tracing the string to the binary.

Impact

Any Spanish-speaking user on Windows (also Catalan; "del" is likewise a contraction there) gets git commit blocked whenever:

  • the commit message contains the word "del" (extremely common — e.g. "esqueleto del proyecto", "fix del bug"), and
  • the command also contains a quoted path with spaces (e.g. git -C "C:\My Repo" ...).

Prior reports (#69461, #73524, #73882) cover the guard mis-attributing the target when a real Remove-Item exists in the command. This report is the complementary verb-side bug: the deletion command itself is hallucinated from quoted string content, so any innocent command can trip it. Unlike the intermittent cases in #69461, this repro is deterministic.

Suggested fix

  • Tokenize with PowerShell's real parser ([System.Management.Automation.Language.Parser]::ParseInput / PSParser) instead of whitespace splitting, so (a) alias detection never matches inside string literals, and (b) argument extraction can never produce a fragment that starts with a quote character.
  • As a cheap guard-of-the-guard: if the extracted "path" begins with " or ', the tokenization is already known to be wrong — don't block on it.

View original on GitHub ↗