A backslash in double quotes walks past the deny rule

Claude Code #100349 (v2.1.293) reports a permission-matching gap: with `"permissions": { "deny": [ "Bash(*zzprobe*)" ] }`, the commands `echo "zzprobe plain"`, `echo 'zzprobe C:\x'` and the unquoted form are all denied — but `echo "zzprobe C:\x"` runs. The rule never mentions a backslash. A realistic rule, `Bash(*rmdir /s*C:**)`, showed the same split: single-quoted path denied, double-quoted path executed. The report notes the miss happens at permission matching, before execution.

Read the caveats honestly. This is the reporter’s own repro on Windows 11 with Git Bash, in a session with `defaultMode: "auto"`; macOS and Linux were not tested, and the issue is still open with no maintainer confirmation of root cause. What it does show is the general shape: a pattern deny list matched against command text is only as good as the parser that normalizes quoting and escapes, and one quoting form can slip past.

Practical takeaway: do not treat Claude Code deny rules as a security boundary. Keep them as guardrails, and put the real boundary somewhere a string match cannot be talked around — a sandboxed workspace or container without credentials you would mind losing, an allowlist of commands instead of a denylist, and approvals for anything destructive. On Windows, test your deny rules against single-quoted, double-quoted, and unquoted variants before you rely on them.