[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

A generic PowerShell permission rule (Tool(prefix*)) already present in both ~/.claude/settings.json (user scope) and the project's .claude/settings.local.json does not prevent the permission prompt from reappearing. A scheduled task runs a fixed script with a variable trailing argument (-LogLine "<text>"), and despite the rule already covering that exact prefix, a permission prompt appears on every run. Clicking "Always allow" does not recognize or reuse the existing generic rule — it writes a brand-new rule instead, and that new rule itself contains a systematic escaping bug: the script path is written with doubled backslashes (\\Claude\\Scheduled instead of a single \Claude\Scheduled), so the newly generated rule can never match the real command either. This reproduces identically across two different execution contexts (an interactive session and a real persistent scheduled task).

What Should Happen?

If a rule like Tool(prefix*) already exists and the executed command starts with that exact prefix, no permission prompt should appear, regardless of the trailing arguments. And if the user does click "Always allow" for some reason, the rule the app writes should use correctly escaped, single backslashes so it actually matches the command it was generated from.

Error Messages/Logs

No error message is shown — the issue is a permission prompt that should not appear, plus a malformed rule silently written afterward. Example of the malformed rule written into settings.local.json after clicking "Always allow" (note the doubled backslashes):
PowerShell(& "$env:USERPROFILE\\Claude\\Scheduled\\backup-claude\\backup.ps1" -LogLine "<literal text of that run>")
compared to the correct, already-present generic rule (single backslashes):
PowerShell(& "$env:USERPROFILE\Claude\Scheduled\backup-claude\backup.ps1"*)
I have a screenshot of the permission prompt dialog itself if useful.

Steps to Reproduce

Add a rule to permissions.allow: PowerShell(& "<fixed path>\script.ps1"*).
Run a PowerShell command starting with that exact prefix, followed by a variable trailing argument, e.g. -LogLine "some plain ASCII text, no special characters".
Observe that a permission prompt appears anyway, even though the command matches the existing generic rule and contains no special characters (tested specifically to rule out em dash / quote characters as the cause — same result with plain ASCII).
Click "Always allow".
Re-read settings.local.json (or settings.json): a new rule was added containing the literal text of this one execution, with the script path escaped as doubled backslashes — so it will never match a future execution (different trailing text) nor even a repeat of the exact same command reliably.
Repeat steps 2–5 via a real persistent scheduled task (not just an interactive session) — same result, ruling out session-specific causes.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Version 1.24012.9 (03c61d)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

<img width="831" height="286" alt="Image" src="https://github.com/user-attachments/assets/e2ab7381-aee6-4cf9-b74d-b82193d1eb95" />