[BUG] ask permission rules with path patterns don't override auto-allow for memory directory
Summary
When autoMemoryEnabled: false is set and memory writes go through the standard Write/Edit tools, patterned ask permission rules targeting the memory directory are silently ignored. Bare ask and patterned deny rules work correctly for the same path. This was discovered when I was trying to require user confirmation for memory writes via ask rules in settings.json.
Environment
- Claude Code version: latest (2026-04-16)
- OS: Windows 11 Enterprise 10.0.26100
- Settings location:
~/.claude/settings.json(global user settings) autoMemoryEnabled: false
Investigation
I tested three permission configurations, each with four operations (Write new / Edit existing, for both memory and non-memory files in ~/.claude/projects/):
| Config | Non-memory Write | Non-memory Edit | Memory Write | Memory Edit |
|--------|:---:|:---:|:---:|:---:|
| No permissions | Prompted | Prompted | Auto-allowed | Auto-allowed |
| ask: ["Write", "Edit"] | Prompted | Prompted | Prompted | Prompted |
| ask: ["Write(~/.claude/projects/*/memory/*)", "Edit(~/.claude/projects/*/memory/*)"] | Prompted | Prompted | Auto-allowed | Auto-allowed |
Non-memory files in ~/.claude/projects/ prompt by default (outside project directory), so those results are baseline behaviour, not caused by my rules.
I additionally tested deny with the same pattern:
| Config | Memory Write | Memory Edit |
|--------|:---:|:---:|
| deny: ["Write(~/.claude/projects/*/memory/*)", ...] | Blocked | Blocked |
Key finding: The path pattern itself matches correctly — deny with the pattern blocks memory writes. But ask with the identical pattern does not prompt. Bare ask (no pattern) does prompt.
Suspected cause
The memory directory appears to have an internal auto-allow that is evaluated after deny and bare ask, but before patterned ask. This means patterned ask rules can never override it. The evaluation order appears to be:
deny (patterned) > ask (bare) > [internal memory auto-allow] > ask (patterned) > default
This is a theory based on observed behaviour — I don't have visibility into the permission evaluation internals.
Expected behaviour
ask: ["Write(~/.claude/projects/*/memory/*)"] should prompt for confirmation on memory file writes, the same way bare ask: ["Write"] does. Patterned and bare ask rules should have equal priority relative to any internal auto-allow.
Workarounds
- Bare
ask: ["Write", "Edit"]works but prompts for all writes/edits, not just memory denyworks with patterns but blocks entirely rather than prompting- CLAUDE.md instruction as soft enforcement (relies on model compliance)
Related issues
- #29098 — Permission patterns don't match paths resolved to relative form
- #39340 — Absolute vs
~path normalization mismatch (duplicate of #29098)
Note: those issues describe path matching failures. This issue is distinct — the pattern matches (proven by deny working), but ask specifically is overridden for memory paths.
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is related to #22055 but not a duplicate. My issue provides controlled evidence that narrows the root cause:
denywithWrite(~/.claude/projects/*/memory/*)blocks the writeaskworks —ask: ["Write"]prompts for the same memory fileaskdoesn't —ask: ["Write(~/.claude/projects/*/memory/*)"]silently auto-allows itThis rules out pattern matching as the issue. The same pattern works in
denybut not inask, which points to an evaluation order problem where an internal auto-allow (specifically for the memory directory) sits between bareaskand patternedaskin the priority chain.#22055 reports the same symptom but doesn't isolate whether patterns fail to match or fail to override. #15237 involves an explicit
allowconflicting withask— mine has noallowrule at all. #37516 is the opposite problem (allowrules being ignored).The full test matrix is in the issue body.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.