Auto memory should be shared across git worktrees of the same repository
When using git worktrees, each worktree gets its own auto memory directory because the path is derived from the working directory:
/Code/app5→~/.claude/projects/-Code-app5/memory//Code/app5-pay-123→~/.claude/projects/-Code-app5-pay-123/memory/
This means learnings recorded in one worktree (e.g. "this billing system counts refunded orders as fulfilled") are invisible when working in another worktree of the same project.
Expected behavior: All worktrees sharing the same git origin should share a single auto memory directory. The memory path could be derived from the repo's remote URL or the main worktree path instead of the current working directory.
Use case: We use worktrees for parallel feature work. Learnings about the codebase (architecture patterns, common pitfalls, domain knowledge) apply across all worktrees. Currently, Claude re-discovers the same things in each worktree independently.
Related issues: #16600, #15776, #16089
8 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate - the suggested issues are actually about different (sometimes opposite) concerns:
This issue specifically requests that the auto memory directory (
~/.claude/projects/<path>/memory/) be derived from the repo identity (e.g. remote URL or main worktree path) rather than the working directory path, so that learnings recorded in one worktree are available in all worktrees of the same repo.This is not really the "opposite" it effectively asks for not loading the "same" project memories multiple times - (due to weird git worktree path structure)
Adding a related angle from #28037 (which I'm closing as a duplicate of this):
Beyond memories being invisible across worktrees, they're also silently orphaned when the worktree is deleted. The memory directory at
~/.claude/projects/-...-worktrees-fix-foo/memory/persists aftergit worktree remove, but no future session will ever load it — the knowledge is effectively lost.This makes the issue more than an inconvenience — it's silent data loss. Users have no indication that memories saved during a worktree session won't survive the worktree's lifecycle.
Also worth noting: the preferred fix here (derive the memory path from the repo root rather than the CWD) would also resolve the duplicate-loading issues in #16600, #24283, and #27082, since there would be only one project directory per repo regardless of which worktree is the CWD.
closed this as completed3 hours ago
would love to know how it is completed!?
Just getting more insights on the problem, @dansv59 the same problem happens if you use the
claude --worktree?Hi @gustavostz! I tested this with Claude Code's built-in worktree feature (claude --worktree). In that case, the worktree is created under .claude/worktrees/ inside the original repo, so the memory path resolves to the main repo's project directory:
Working dir: /Users/daniels/Code/portfolio-mcmc/.claude/worktrees/polymorphic-humming-russell
Memory path: ~/.claude/projects/-Users-daniels-Code-portfolio-mcmc/memory/
So built-in worktrees don't have this problem — memory is shared with the main repo. But this only works because the worktree happens to be nested inside the original repo's directory tree. It's a side effect of the directory structure, not an actual fix.
Manually created worktrees (e.g., git worktree add ../my-feature) still get a separate memory path based on the CWD, so the core issue remains: memory path derivation is based on the working directory rather than repo identity.
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.