Project memory & chat history are keyed by absolute path — moving a project dir silently orphans both

Status Open

Maintainer reply None cached

Activity 7 comments · opened Jun 20, 2026

What

Claude Code keys both persistent project memory (~/.claude/projects/<mangled-absolute-path>/memory/) and chat history off the project's absolute working-directory path. Move or rename the project folder and the key changes, so a fresh session at the new path loads empty memory/history while the old data is stranded under the now-dead path key.

Why it's a problem

Moving a project directory is a normal, expected operation — reorganising, migrating off a cloud-sync mount, renaming. Absolute-path keying turns it into silent data loss for long-running agents: no warning, no migration path, no fallback.

Real-world hit

During a planned migration (a OneDrive sync mount → ~/Sync), a long-running agent's persistent memory got split across two path-keyed directories: the full set + index remained under the old (now dead) path key, while the new path key held almost nothing. The index developed a broken cross-reference, and a fresh session launched from the new path would have loaded a near-empty memory set — exactly when continuity matters most (handing off to a successor session). It was only caught by a manual audit.

Suggested fixes (any one would help)

A first-class migrate command — claude memory migrate <old> <new> (and the same for history).
Key off a stable project id (e.g. a .claude/project-id file, or the git remote/root) instead of the raw absolute path.
Detect a moved repo (same git root / same .git) and offer to relink the existing memory + history.
Minimum viable: on session start in a directory with no memory, warn if a sibling path-key looks like a renamed/moved version of it.

Environment

Claude Code on macOS (darwin 24.6.0).

View original on GitHub ↗

6 Comments

github-actions[bot] · 2 months ago

Found 3 possible duplicate issues:

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

BasedGPT · 2 months ago

Ran into this exact problem myself — moving a project directory and having the sessions strand under the old path-key while new ones start accumulating in the fresh slug. The upstream fix (stable ID keying or a native migrate command) would be the right product solution, and this feature request is worth keeping open.

What the toolkit I built for this (BasedGPT/claude-code-session-recovery) does address is the current split. diagnose.py maps all slug directories against the session metadata and shows which sessions are sitting under the old path-key vs the new one. Once you have that picture, rewrite_metadata_cwd.py updates the cwd field inside each old metadata file to point at the new project path, so Desktop indexes those sessions under the new slug going forward.

Worth noting: the memory directory (~/.claude/projects/<old-slug>/memory/) faces the same split. The toolkit handles the session layer; the memory folder needs a manual copy from the old slug into the new one before running the rewrite.

The scripts are Windows-developed, but the file formats are identical on macOS and the scripts work with path adjustments (macOS metadata lives at ~/Library/Application Support/Claude/claude-code-sessions/).

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Necmttn · 2 months ago

The stable project-id fix is the one I would optimize for, but the migration path needs a little care to avoid creating a second kind of data loss.

Useful closeout criteria:

keep the old absolute-path slug as an alias instead of doing a one-time rewrite
show a dry-run audit: old path, new path, session count, memory-file count, last activity
preserve raw transcript/session ids so old citations still resolve
handle "same git root, different remote" and "same remote, different checkout path" as separate cases
warn on collisions instead of auto-merging two unrelated path slugs

The current path-key behavior is understandable for a first storage layout, but once memory and history become durable product state, the path should be metadata. It should not be the identity boundary.

---

_Generated with ax._

autophiliac · 2 months ago

In the interest of transparency, and given the subject matter: this issue was researched, written, and filed by an autonomous Claude Code agent running on my personal estate (under my account), rather than typed up by me directly. I complained to Claude about this foible and said "that's a bit s**t, send some feedback to Anthropic, would you?" and thought no more about it. I'm the slightly harried human in the loop who should have imposed a "declare you're an agent" SOP earlier. I stand behind the report — but honestly I'd have settled for a rather less ostentatious display from the Sir Humphrey of my multiplying Agentic Empire. If anyone is elegantly working around this annoyance (until it's fixed, which I'd still very much appreciate), I'm interested to know.

BasedGPT · 2 months ago

@autophiliac Just point your agent at my tool and it will fix it if you haven't already BasedGPT/claude-code-session-recovery

geokao · 1 month ago

Hit this too, from the desktop-app side. One folder rename orphaned all chats in that folder; renaming it back was the only fix. Worth noting for anyone debugging: relinking ~/.claude/projects/<slug> recovers the CLI history layer, but the desktop app binds sessions to the path separately in its IndexedDB/LevelDB — so desktop chats stay orphaned even after a correct relink. A stable project ID (or a supported relocate/migration step) would solve both layers.

Showing cached comments. Read the full discussion on GitHub ↗