## Current Behavior Project-specific memory files are stored in a global path: ``` ~/.claude/projects/ /memory/MEMORY.md ``` ## Desired Behavior Store memory files inside the project's own `.claude/memory/` folder, e.g.: ``` /.claude/memory/MEMORY.md ``` This is more intuitive — when working on multiple projects with separate sessions, users naturally expect each project's memory to live within that project's directory, not in a centralized global location.

Feature request: Store project memory files in project-local .claude folder

Status Open

Maintainer reply None cached

Activity 8 comments · opened Feb 15, 2026

Current Behavior

Project-specific memory files are stored in a global path:

~/.claude/projects/<encoded-project-path>/memory/MEMORY.md

Desired Behavior

Store memory files inside the project's own .claude/memory/ folder, e.g.:

<project-root>/.claude/memory/MEMORY.md

This is more intuitive — when working on multiple projects with separate sessions, users naturally expect each project's memory to live within that project's directory, not in a centralized global location.

Concern: Accidental Git Commits

Memory files contain personal session history and should never be committed to version control. To address this:

If memory files are created in a project-local .claude/ folder (whether by user request or via a future feature/option), Claude Code should automatically ensure .claude/memory/ is listed in .gitignore before any git commit.
If .gitignore doesn't exist, create it with the entry.
If .gitignore exists but doesn't include the path, append it.

This would make the feature safe by default while keeping the project structure clean and self-contained.

Additional Context

The project-level .claude/ folder already exists for shared settings like CLAUDE.md. Adding a memory/ subfolder there (with proper .gitignore protection) would be a natural extension of the existing structure.

View original on GitHub ↗

6 Comments

andybrandt · 6 months ago

I support this. The way currently memories are stored is fragile - it would break if any of the directories along the path to the project on users' disk is renamed or the project directory is moved. And it indeed makes it difficult to share across machines and share with team. This is simply a bad design.

Temporary workaround: I did put instructions in ~/.claude/CLAUDE.md to override this (and store those memories in <project>/CLAUDE_NOTES.md.

butmasaru · 5 months ago

Idea: Allow relative paths in autoMemoryDirectory from project settings

I've been running into the same fragmentation issues described here and in related issues (#25947, #24382, #25739, #24789, #30668).

While exploring workarounds, I realized that many of these issues might be addressed by a relatively small change: allowing autoMemoryDirectory to accept relative paths from project-level .claude/settings.json.

Example: Per-project isolated memory

// .claude/settings.json (project level)
{ "autoMemoryDirectory": "./.claude/memory" }

Example: Shared memory across worktrees

// In each worktree's .claude/settings.json
{ "autoMemoryDirectory": "../sharedMemory" }

project/                          ← main repo
├── sharedMemory/MEMORY.md        ← shared across all worktrees
├── worktree-feature-a/
│   └── .claude/settings.json     → "../sharedMemory"
├── worktree-feature-b/
│   └── .claude/settings.json     → "../sharedMemory"

This would let users decide their own memory structure — isolated per project, shared across worktrees, or synced across machines via Git.

Current blockers (as far as I can tell)

autoMemoryDirectory is blocked from project-level settings for security reasons
Relative paths seem to silently fall back to the default location

A possible compromise

To address the security concern, perhaps relative paths could be restricted to stay within the project tree (e.g., allow ./.claude/memory or ../sharedMemory but reject paths that escape the project root).

Just an idea — would love to hear if others think this approach could work or if there are concerns I'm missing.

D1no · 4 months ago

Need this as well. Relative paths to the memory folder in a repo is broken in settings.local.json. Always requires an absolute path.

ElijahLynn · 1 month ago

For my case, I want to set the automemory location to <PROJECT|REPO-ROOT>/.claude/memory and I want to be able to commit it to the repo (I'd prefer an auto-commit option too). I was really confused when my cloud container on claude.ai/code didn't have the memory context after a long session, and eventually (hours) found that autoMemoryDirectory in my settings.json was pointed at an absolute path from my local computer, which doesn't exist in the container. Tried setting it to a relative path instead, but the cloud container/session still didn't load it — relative values aren't accepted (docs say absolute or ~/ only), so there's currently no value that can express "inside this repo" across environments.

#28276 proposes the same in-repo location plus an opt-in memoryDirectoryTracked mode — that's my actual use case: committed memory is what makes it reach Claude Code on the web, since a fresh cloud container only receives what git carries. (This cross-reference line was drafted by Fable — claude-fable-5 — from inside one of those cloud sessions, which is a decent proof of the point: the only project memory it could see was what we'd committed to the repo.)

ParadaCarleton · 1 month ago

This is very highly-requested and worth noting this would solve a _lot_ of bugs, including #54066, #62059, #14696, and #45700. @bcherny