Routines: existing .claude/settings.json wildcard permission rule for compound PowerShell command not honored on scheduled run (no prompt should appear)

Summary

In the Claude Code desktop app's Routines (scheduled tasks) feature, a project-level permissions.allow wildcard rule in .claude/settings.json that matches a compound PowerShell command (cd "<dir>"; python -m <module> <subcommand> *) is not honored on every scheduled run — the routine still prompts "Allow once / Deny" for the exact command the wildcard should cover. A newly-added rule for a different subcommand of the same underlying script (in the same routine, same run) worked correctly and also offered an "Always allow" button, while the two pre-existing rules did not offer "Always allow" at all — only "Allow once"/"Deny" — suggesting the permission matcher considered them already "covered" by something, without actually applying that coverage.

This defeats the purpose of a scheduled/unattended Routine: a task meant to run every 30 minutes with no human present stalls on a permission prompt that nobody is there to click.

Environment

• Claude Code desktop app (Windows 11)
• Feature: Routines (scheduled tasks), local task running on a */30 * * * * cron schedule
• Project has both .claude/settings.json (shared/project) and .claude/settings.local.json, the latter with "defaultMode": "auto"

Steps to reproduce

1. Create a scheduled Routine whose prompt runs a PowerShell tool call shaped like:

cd "C:\some\dir"; python -m some_module some_subcommand --flag value

1. Add to the project's .claude/settings.json:

``json
"PowerShell(cd \"C:\some\dir\"; python -m some_module some_subcommand *)"
``

1. Let the routine fire on its schedule (not a manually-typed interactive message).

Expected

The compound command matches the wildcard rule and runs without any prompt, exactly as it would for a simpler Bash(cmd *)/PowerShell(cmd *) rule.

Actual

• The routine still shows an "Allow once / Deny" prompt for the command, even though the wildcard rule was added to .claude/settings.json hours before the run in question (added at 00:12, prompt still appeared at a run at 14:11 the same day).
• No "Always allow" option is offered for that prompt — only "Allow once" and "Deny".
• In the same run, a third PowerShell command (for a different subcommand of the same script, added to .claude/settings.json for the first time just before this run) correctly triggered an "Allow once / Always allow / Deny" prompt with all three options, and clicking through worked as expected.

This suggests the routine's permission check either isn't reading the project .claude/settings.json wildcard rules consistently, or there's a matcher bug specific to compound cd ...; ... PowerShell commands, or a stale/narrower rule in .claude/settings.local.json (added earlier via a previous "Always allow" click, before the routine's commands were changed to prepend cd "<dir>";) is short-circuiting the match without actually satisfying it — which would also explain why "Always allow" wasn't offered (the system may think it's "already handled").

Impact

A Routine intended to run fully unattended every 30 minutes cannot do so reliably — it silently blocks on a permission dialog with nobody to click it, so scheduled runs effectively stop making progress until a human happens to open the app and click through.

Request

• Please confirm whether project-level .claude/settings.json wildcard allow rules are read for scheduled Routine executions the same way they are for interactive sessions.
• Please check whether an older, narrower rule (e.g. an exact-match rule from a previous "Always allow" click, made before a command's shape changed) can suppress the "Always allow" offer for a newer, technically-non-matching invocation of a similar command, without actually granting the permission.