permissions.deny Read rules cannot fence the project auto-memory directory (~/.claude/projects/<cwd-slug>/memory/*)

Summary

On Claude Code 2.1.233 (Linux, headless claude -p usage), permissions.deny Read rules do not block reads of the current project's auto-memory directory (~/.claude/projects/<cwd-slug>/memory/*). The directory appears to have a structural exemption keyed off the cwd's project slug, independent of the deny rules and of the auto-memory feature flag.

Reproduction (verified three independent ways, 2026-08-14, v2.1.233)

Running a headless session with --permission-mode dontAsk and a settings payload containing each of the following, the model could still Read files under the current project's memory dir in full:

1. A glob deny: "deny": ["Read(~/.claude/**)"] — other ~/.claude paths are denied as expected; the current project's projects/<cwd-slug>/memory/* files are still readable.
2. An exact literal-path deny on one specific memory file — that exact file is still readable.
3. CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 in the environment — memory is not injected automatically, but explicit Read of the memory files still succeeds.

A control shows deny rules working normally for non-memory paths in the same session (tool_result errors: "File is in a directory that is denied by your permission settings").

Why it matters

Deny-rule-based read-only containment (e.g. a sandboxed evaluation/probe agent given --tools Read,Grep,Glob plus a deny list) cannot fence memory content for any cwd whose slug has an existing memory directory. Project memory dirs commonly contain exactly the kind of environment/infrastructure notes a contained agent shouldn't see. The only workaround we found is running contained sessions from a freshly-created path whose slug has no memory directory — which we now enforce mechanically on our side.

Expected

Either permissions.deny Read rules apply to the project memory directory like any other path, or the exemption is documented so containment designs don't assume deny coverage there.

Related

• #73893 (subagents accessing paths outside approved permission boundaries — same "boundary has an exemption" shape)
• #30519 (permissions matching meta-issue)