[BUG] Auto-memory Edit/Write to ~/.claude/projects/*/memory is gated as a sensitive file in project-cwd sessions; "always allow" doesn't persist (2.1.215)

Environment

• Claude Code v2.1.215 (also reproduced on 2.1.201), VS Code extension, Windows 11
• Auto-memory enabled (default)

Summary

When Claude updates one of its own auto-memory files under ~/.claude/projects/<slug>/memory/ from a session whose working directory is a project (i.e. not $HOME), the Edit/Write is blocked by the "sensitive file" gate and prompts for approval every time. Choosing "always allow" does not persist across sessions. (This is the behavior behind the now-closed-and-locked #16762 / #43001.)

Why it matters

Auto-memory instructs the model to update an existing memory file rather than duplicate it. That update is an Edit (or overwrite Write) on a path under .claude/, which the harness classifies as sensitive. So routine, first-party memory maintenance raises a permission prompt on essentially every project-directory session, and the prompt cannot be silenced by configuration.

Reproduction

1. Work in a session whose cwd is a project outside $HOME (e.g. C:\code-one\myrepo); let auto-memory accumulate a file under ~/.claude/projects/<sanitized-cwd>/memory/.
2. Have Claude update that memory file (Edit, or overwrite Write).
3. A prompt appears: "…is a sensitive file". "Always allow" does not persist — it re-prompts next session.

Diagnosis (headless probes on 2.1.201 and 2.1.215 + classifier inspection)

The sensitive-file classifier flags any path containing a .claude segment (only .claude/worktrees is exempt). The check sits above permission-rule resolution, so none of these clear it:

• permissions.allow — bare "Edit"/"Write" or path-scoped Edit(**/.claude/projects/**) / Write(...)
• permissions.additionalDirectories (including the memory dir itself)
• the --allowedTools CLI flag (scoped or bare)
• --permission-mode dontAsk (which auto-denies, so the write silently fails)

Control: editing a file that is out-of-workspace but not under .claude and is listed in additionalDirectories (e.g. under %TEMP%) succeeds. So the block is specifically the .claude location applied to Claude's own memory store — not a general out-of-workspace restriction.

Current workaround

Set autoMemoryDirectory to a path outside .claude. Note it must be per-project via .claude/settings.local.json, because a single user-level value is used literally (no per-cwd subdir), which would merge every project's memories into one directory.

Suggested fix

Treat the resolved auto-memory directory as non-sensitive for the memory subsystem's own Edit/Write (analogous to the existing .claude/worktrees exemption), or persist "always allow" for these paths so approval is a one-time cost.