[FEATURE] Portable project memory across machines (multi-device workflow)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23321
2. https://github.com/anthropics/claude-code/issues/24980
3. https://github.com/anthropics/claude-code/issues/24382

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

Have you seen this project?

https://github.com/kneetworks/claude-sync

This matches a core problem I ran into too — different absolute paths between machines breaking session continuity. I built claude-context-sync which solves the path issue by converting absolute paths to template variables (${PROJECTS}, ${HOME}, etc.) during export and restoring them on import.

It doesn't sync memory in-place inside the project folder, but it does let you carry full session context (messages, file history, todos) between machines via a Git repo, even when paths differ. Might be useful as a workaround until a native solution ships!

We solved this for our own workflow with user-memories - a standalone knowledge extraction system that syncs across machines.

The approach: instead of syncing Claude Code's internal project memory files, we extract knowledge into a SQLite database with semantic embeddings. The DB file is small (usually under 50MB even for large projects) and easy to sync via git, Dropbox, or rsync. On each machine, a CLAUDE.md instruction points Claude to query this shared knowledge base.

The key advantage over syncing ~/.claude/projects/ directly: semantic search means the right context surfaces regardless of which machine created it. A memory created on your workstation about "the auth module uses JWT with RS256" will match when you are on your laptop asking about authentication, even if the path-derived project key differs.

For the path-derivation problem specifically, we hash the git remote URL instead of the local filesystem path. Two clones of the same repo on different machines produce the same project key. This would be a relatively simple fix in Claude Code's own memory system.

The user-memories project that handles cross-machine knowledge sync: https://github.com/m13v/user-memories/blob/main/user_memories/db.py

Embedding-based semantic retrieval so memories match by meaning, not path: https://github.com/m13v/user-memories/blob/main/user_memories/embeddings.py

Exact same problem here — the path-derived directory names under ~/.claude/projects/ make it impossible to share project memory across machines with different usernames or directory structures.

I built claude-brain to solve this. It syncs your entire Claude Code brain (memory, skills, agents, rules, settings) across machines via Git with semantic merge. The key thing it handles is the path normalization problem — your project context follows you regardless of where the project lives on each machine.

Setup is just claude-brain init + claude-brain push/pull. Would love native support from Anthropic eventually, but this covers the gap for now.

+1 to this — and I'd love to extend the use case beyond single-user multi-device to team collaboration.

We work on a SaaS project with multiple developers. Right now, all the project context Claude builds up — coding conventions, architectural decisions, phase progress, gotchas — lives in ~/.claude/projects/ on one person's machine. When another team member opens the same project, Claude starts from scratch and has to rediscover everything.

If project memory lived inside the repo (e.g. .claude/memory/), it would:

• Sync across machines naturally via git pull
• Be shared across the whole team, so every developer's Claude instance has the same context
• Survive machine wipes, new setups, and onboarding new developers

The proposed .claude/memory/ project-relative approach is elegant — it follows the same pattern as the existing .claude/settings.json. A simple opt-in flag to commit it to git (vs. .gitignore by default) would give teams full control.

First-class team memory would be a genuine force multiplier for engineering teams using Claude Code on shared codebases. Huge appreciation for the team — this is an amazing tool and we're just hoping to squeeze even more out of it. 🙏

yeah the path-derived names are the core problem. git remote URL hashing solves it because the repo identity is the same regardless of where it's cloned. we hash the remote origin URL and use that as the directory name under .claude/projects/ - means two machines pointing at the same repo share the same memory space. not perfect (forks get separate memory) but it covers the common case

team collaboration is the obvious next step yeah. we haven't tackled that yet but the architecture would be similar - you'd want a shared memory layer (probably backed by the git repo itself, like a .claude/ directory that gets committed) plus personal overrides that stay local. the tricky part is merge conflicts in memory files when two people are working concurrently

For the export/import side of this, I have a plugin that might help: claude-memory-manager

It includes a web UI where you can select memories, export them as a .zip (with a manifest tracking which container they came from), and import on another machine. Not a sync solution, but a manual workaround for moving project memory between devices.

<img width="1280" height="679" alt="Image" src="https://github.com/user-attachments/assets/da4be484-5e08-4cae-bf59-4ea74330f120" />

this is a nice practical workaround. the web UI for selective export is a good design choice - beats dumping everything. do you handle merging when importing into a machine that already has memories for the same project? that's where the tricky conflicts come in, especially when two machines have diverged on the same memory entry.

Thanks for the kind words! Import is just copying md files + merging the MEMORY.md index. Same-name files get overwritten, different names coexist. If there are duplicates, just delete them in the Web UI.

good to know the import is that simple. the same-name overwrite behavior makes sense for keeping things clean. for anyone reading this, one tip: use descriptive filenames in your memory files (like feedback_testing.md, project_auth_rewrite.md) rather than generic names, so the overwrite-on-import behavior works in your favor instead of accidentally clobbering unrelated memories.

Same pain point here. Our workaround: a private Git repo for ~/.claude/ using a targeted .gitignore that includes only projects/*/memory/**, global skills, and settings.json. Works well as a backup and for reading context on another machine, but the path-derived directory names mean memories don't auto-load on a machine with a different username or directory layout — you'd have to symlink manually.

The git-remote-URL-hashing approach mentioned above feels like the right native fix: repo identity is stable across machines regardless of local path. A memoryDirectory setting in settings.json as a simpler alternative would also cover the case where users want to manage the location themselves.

The git repo for ~/.claude/ is a pragmatic workaround. We do something similar but ran into the same path-derived directory issue you described.

The git-remote-URL-hashing approach would fix the cross-machine problem properly. The other piece that would help: a merge strategy for memory conflicts. If two machines both update the same memory file between syncs, you need a way to resolve that without manual intervention. Last-write-wins is simple but lossy. An append-and-deduplicate strategy for memory entries would preserve both machines' observations.

The symlink workaround works but it's fragile - any tool that resolves symlinks before writing will break it. We've had Claude Code itself resolve the symlink and write to the target path directly in some cases.

My vote too for this request feature!

We built an open-source tool that solves this — MemRoach.

Instead of syncing files, it backs up your Claude Code memory (.claude/ — memory files, skills, settings) to a central CockroachDB instance. Lose your laptop, switch machines, or do a fresh install — one pull command and your AI picks up exactly where it left off.

Key differences from file-sync approaches (Git, rsync, Dropbox):

• Content-addressable dedup — same content is never stored twice
• Semantic search over all your memories (hybrid keyword + vector)
• Version history and audit log
• Column-level AES encryption — content encrypted client-side
• Auto-sync via Claude Code hooks (push on session end, pull on session start)
• MCP server so Claude can read/write memories as native tools

Setup takes ~5 minutes. Happy to answer any questions.

MemRoach looks interesting - content-addressable dedup for .claude/ files is a smart approach. The main challenge with file-sync tools (Git, rsync) for this use case is conflict resolution when the same memory gets updated on two machines. How does MemRoach handle that? Last-write-wins, or some kind of merge strategy?

Also curious about the CockroachDB requirement - is that for the distributed consistency guarantees, or would a simpler backend (SQLite + sync) work for single-user setups?

Great questions!

Conflict resolution: MemRoach doesn't do last-write-wins. It has a semantic merge strategy — when the same memory file is updated on two machines, it uses LLM-powered consolidation to merge both versions intelligently, deduplicating overlapping content while preserving unique observations from each machine. For non-memory files (skills, settings), it uses content-hash comparison and keeps the most recent version with full version history, so nothing is lost — you can always roll back.

Why CockroachDB: A few reasons beyond just distributed consistency:

• Native encrypt()/decrypt() SQL functions for column-level AES encryption — content is encrypted at rest without any application-layer crypto complexity
• Vector column support (VECTOR(1024)) for semantic search embeddings, no separate vector DB needed
• Multi-user / team use case works out of the box — row-level security, RBAC, and per-user scoping are built in
• Serverless tier is free for small workloads, so there's no infra cost for individual users

That said, the sync logic is pretty backend-agnostic — the core is just content-addressable blobs + metadata. A SQLite + sync adapter would be a reasonable contribution for fully offline single-user setups.

The semantic merge for memory files is clever. LLM-powered consolidation makes way more sense than last-write-wins for this use case since two machines might observe different things about the same topic.

What model are you using for the consolidation step? And is there a size threshold where you split memories into separate files to keep the merge diffs manageable?

Real-world case: laptop dies, 130 sessions of memory gone

I keep my project on a Google Drive shared drive specifically for portability. Code, env files, settings backups - all survived a laptop transition. The one thing that didn't: Claude Code memories.

130+ sessions of accumulated context - collaboration preferences, debugging history, architectural decisions, feedback corrections - all stored in ~/.claude/projects/ keyed to an absolute path hash that has no relationship to the project directory. No way to sync it, export it, back it up, or point it somewhere else.

The irony: I did the responsible thing by putting my project on a shared drive. Claude Code then stored the most valuable accumulated context - the thing that makes session 131 smarter than session 1 - in the one place that doesn't travel with the project.

What would have saved me: Any of the proposed solutions in this issue. Project-relative memory (.claude/memory/ in the project dir) would have been seamless - it would have synced with everything else automatically.

Even Anthropic's own Scuttle (the companion cat in Claude Code) agrees:

yawns, ignores the feature request entirely Absolute paths are antisocial. Move projects, lose memories. Design flaw.

+1 for this. It's not an edge case - it's anyone who works across machines, reformats, or has hardware fail.

I solved this with Syncthing (LAN-only, zero cloud) + a CLAUDE.md rule that forces Claude to write memory inside the project folder instead of .auto-memory/. Mac = Send Only, Windows = Receive Only. Context syncs in seconds.

The missing piece most solutions overlook: by default Claude writes to .auto-memory/ outside your project. Adding a rule in CLAUDE.md to redirect memory writes to a memory/ folder inside the project makes everything portable.

Full writeup with install commands and config: https://alebrije.io/blog/never-re-explain-sync-claude-memory-mac-windows/

+1 ... how does this not exist. My memory files are a circus across so many machines.

Sharing a symlink-based approach that's been working well across Linux and macOS.

The core idea: instead of exporting memory out of ~/.claude/projects/ or building a sync layer on top, make ~/.claude/projects/ itself a symlink pointing into a private git repo. Claude Code writes directly to the versioned directory — no import/export step, no intermediate tool.

~/.claude/projects/ -> ~/misRepos/myClaudeContext/projects/

The repo is cloned on every machine. A setup script creates the symlink, and from that point the workflow is:

• Arriving: memory-pull (git pull with integrity checks)
• Leaving: semantic commit + git push (or a fallback script if Claude isn't active)

There's also a memory-check script for integrity validation (broken symlinks, diverged remotes, untracked files), a memory-audit script for periodic cleanup of orphaned project directories, and a bootstrap.sh for first-time setup on a new machine.

What it does and doesn't solve:

It doesn't fix the path-derivation problem natively — Claude Code still keys project memory to the absolute path hash, so this only works if you maintain consistent paths across machines (same username, same directory structure). If that constraint fits your setup, you get full memory portability with no external infrastructure.

What it adds beyond the ~/.claude/ git repo approach mentioned by @yaccob: the symlink means Claude writes to git directly — no manual copy step. It also extends naturally to multiple agents: Gemini CLI points to the same files via its own symlink, with per-agent instruction sections in a shared CLAUDE.md ([Solo Claude Code] / [Solo Gemini]).

macOS note: on macOS, ~/.claude/projects/ must be a real directory (not a symlink). The repo includes platform-specific scripts that handle this: pull copies dirs from the repo into local, push copies them back before committing. Path translation between -home-<user>- and -Users-<user>- is handled automatically.

Template with setup scripts and full documentation: https://github.com/mmasias/myClaudeContext-template

+1 with a specific direction.

Long-term Claude Code users build substantial memory over weeks/months: rules, philosophy, design preferences, session history, work plans, lessons learned. On Windows, the default ~/.claude/ maps to C:\Users\<user>\ — a path most users don't include in their backup rotation. Three months of accumulated context can vanish on a single disk failure or machine migration.

I understand the reasoning behind keeping things local — Claude Code touches source code, secrets, env vars, transcripts that may contain PII. Cloud sync of raw data would create real privacy risk. That's a legitimate, well-thought-out default.

But there's a hybrid that doesn't force the trade-off:

1. Memory stays local by default — same as today.
2. Optional sync to Anthropic-account cloud — but with automatic AI-driven redaction before upload:

• Claude itself filters out secrets, API keys, passwords, PII, IP addresses, specific paths, env values, etc.
• Same kind of analysis /security-review already does — applied continuously to memory writes.
• User sees what was redacted (transparency) and can accept/reject.

1. Cloud holds only the sanitized layer: rules, philosophy, design preferences, lessons-learned patterns, structure templates. Not transcripts, not code, not secrets.
2. Install on a new machine:

• Login with Anthropic account → "Pull memory from cloud?" prompt
• User chooses local directory (D:\, OneDrive, custom path)
• Sanitized memory layer is restored
• Project-specific transcripts/code stay where they were (or get re-accumulated)

This pairs the best of both models: local-first for sensitive data (the current correct default), cloud-synced for accumulated meta-knowledge that's hardest to rebuild.

It also leverages something Anthropic uniquely has — an AI capable of understanding what's sensitive vs. what's a user-curated rule. Other vendors can't do this filtering well; Anthropic can.

Maintainer disclosure: I maintain an unofficial local-first session transfer tool.

This does not solve project-relative memory as an official Claude Code feature, but it may help with the adjacent portability problem: cct can export/import local Claude Code sessions from ~/.claude/projects/..., and supports path remapping with --map-cwd OLD=NEW when moving between machines or different absolute project paths.

https://github.com/ahmojo/codex-claude-transfer

It is not cloud sync, not account-level sync, and not for normal claude.ai chats. It works only with local Claude Code transcript files.