Edit/Write tool approval not honored by settings.local.json wildcard (Read works, Edit doesnt)

Description
On Windows, a permission entry in .claude/settings.local.json such as "Edit(//c/Users/<user>/.../data/**)" does not suppress the approval prompt for the Edit tool - even though an identical-pattern Read(//c/Users/<user>/.../data/**) entry for the same file does suppress it. This causes an unattended/scheduled-task run to stall indefinitely waiting for manual approval.

Repro context

• Windows 10, Bash tool (git-bash backed)
• .claude/settings.local.json contains (paths abbreviated): Read(//c/.../data/**), Write(//c/.../data/**), Edit(//c/.../data/**)
• A scheduled-task session called Read on data/daily_data_YYMMDD.json -> returned instantly, no prompt.
• The same session then called Edit on the same file (matching the same wildcard pattern) -> the call hung for ~1h44m until a human manually approved it later.
• Bash commands (exact-match and wildcard * entries) in the same session were unaffected - only Edit showed this behavior. Write is untested.

Expected: Edit should honor the Edit(...) wildcard the same way Read honors Read(...).

Impact: Breaks unattended/scheduled-task workflows that need to programmatically edit files - no one is present to approve, so the run stalls indefinitely.

Workaround: Route the mutation through Bash (node -e '...') instead of the Edit tool.