permissions.deny Bash rules stop matching when the command contains a backslash inside double quotes

What happens

A permissions.deny rule for Bash stops matching as soon as the command contains a
backslash inside a double-quoted string, even when the rule's pattern does not involve
the backslash at all. The command then runs without being denied.

Environment

• Claude Code 2.1.293
• Windows 11 (10.0.26200), Git Bash
• permissions.defaultMode: "auto"
• Rules in project .claude/settings.json (hot-reloaded; control probes in the same minute were denied)

Reproduction

Add a deny rule unrelated to backslashes:

"permissions": { "deny": [ "Bash(zzprobe)" ] }

Then ask Claude to run each of these harmless commands:

| Command | Expected | Actual |
|---|---|---|
| echo "zzprobe plain" | denied | denied |
| echo 'zzprobe C:\x' | denied | denied |
| echo zzprobe C:\\x | denied | denied |
| echo "zzprobe C:\x" | denied | runs |

Same result with a realistic rule, Bash(*rmdir /s*C:**):
echo 'rmdir /s /q C:\zz-test' is denied, echo "rmdir /s /q C:\zz-test" runs.

Impact

Deny rules are the only guard that cannot be overridden by an allow rule. Any destructive
Windows command written with a quoted path (cmd //c "rmdir /s /q C:\...") skips every deny
rule, and no rule syntax can close it, since the rule never gets evaluated against that form.

Ruled out

• Rule syntax: the failing rule has no backslash; the same rule denies the single-quoted and

unquoted forms.

• Settings not reloaded: control probes with the same rule were denied right before and after.
• Not tested on macOS/Linux.

Possibly related

#89392, #85856, #97409 (Windows Bash tool backslash handling at execution time). This report
is about permission matching, before execution.