[BUG] ask permission rules with path patterns don't override auto-allow for memory directory

Status Fixed / completed
Maintainer reply None cached
Activity 3 comments · opened Apr 16, 2026 · closed Apr 17, 2026

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
  • deny works 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.

View original on GitHub ↗

3 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/22055
  2. https://github.com/anthropics/claude-code/issues/15237
  3. https://github.com/anthropics/claude-code/issues/37516

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

RalphSleiman · 6 months ago

This is related to #22055 but not a duplicate. My issue provides controlled evidence that narrows the root cause:

  1. The pattern itself matches — deny with Write(~/.claude/projects/*/memory/*) blocks the write
  2. Bare ask works — ask: ["Write"] prompts for the same memory file
  3. Patterned ask doesn't — ask: ["Write(~/.claude/projects/*/memory/*)"] silently auto-allows it

This rules out pattern matching as the issue. The same pattern works in deny but not in ask, which points to an evaluation order problem where an internal auto-allow (specifically for the memory directory) sits between bare ask and patterned ask in 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 allow conflicting with ask — mine has no allow rule at all. #37516 is the opposite problem (allow rules being ignored).

The full test matrix is in the issue body.

github-actions[bot] · 5 months ago

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.