Windows: PowerShell allow rule auto-written on 'approve & don't ask again' fails to match identical subsequent invocations

Resolved 💬 3 comments Opened May 7, 2026 by MrAi410 Closed May 11, 2026

Environment

  • Claude Code: 2.1.132
  • OS: Windows 11 Pro 10.0.26200
  • Shell: Windows PowerShell 5.1 (the built-in PowerShell tool, not Bash)

Summary

When I run a PowerShell-tool command, click "Yes, and don't ask again", then run the exact same command later, the prompt fires again. Inspecting .claude/settings.local.json shows the harness did write an allowlist entry on approve — but that entry never matches the very command that produced it.

Reproduction

  1. In a Windows project, have a script at .\tools\Render-Pdf.ps1.
  2. Have Claude run it via the PowerShell tool: .\tools\Render-Pdf.ps1 some-file.md.
  3. At the permission prompt, choose "Yes, and don't ask again."
  4. Confirm .claude/settings.local.json now contains an entry written by the harness:

``json
"PowerShell(.\\tools\\Render-Pdf.ps1 some-file.md)"
`
(Four backslashes per separator in JSON, i.e.
\` between path segments after deserialization.)

  1. Have Claude run the same command again: .\tools\Render-Pdf.ps1 some-file.md.

Expected

No prompt — the rule matches.

Actual

The prompt fires every time. Choosing "approve & don't ask again" again does not append a duplicate entry; the line is already there. The matcher is not seeing the existing rule as a match.

Evidence

A real entry the harness auto-wrote in our settings.local.json (verbatim):

"PowerShell(.\\tools\\Render-Pdf.ps1 desmond-to-a410-map.md)"

The command that triggered it (and that we re-ran multiple times, getting prompted each time):

.\tools\Render-Pdf.ps1 desmond-to-a410-map.md

Hypothesis

The auto-write looks over-escaped: the rule body deserializes to .\tools\Render-Pdf.ps1 … (double-backslash between segments), but the actual command string the matcher sees has single backslashes (.\tools\Render-Pdf.ps1 …). If the matcher is doing a literal/prefix string compare, the two will never match — so the harness has persisted a rule that is structurally guaranteed not to fire.

Wildcard variants in .claude/settings.json (e.g. PowerShell(.\\tools\\Render-Pdf.ps1 *) and PowerShell(.\tools\Render-Pdf.ps1 *)) also fail to match. We could not find any rule shape that suppresses prompts for PowerShell-tool invocations of .ps1 scripts on Windows.

Impact

On Windows, "approve & don't ask again" for any PowerShell tool command silently fails — users are prompted indefinitely for the same command. The settings file fills with rules that don't do anything.

Workaround

None we could find. Bash-tool rules and rules using forward slashes appear unaffected; the bug seems specific to PowerShell-tool rules with backslash-bearing paths.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗