[Feature Request] Cross-device identity: account-bound memory across multiple machines

[malanmurphy]

Problem

I'm a small business owner and PM working across a desktop, two laptops, and an iPhone. I use Claude Code on my primary machines and Claude Desktop and the iOS app on the others — but I'm working on the same projects across all of them.

The fundamental issue isn't sync. It's identity. Claude Code has no concept of "this user" — only "this filesystem path." Every device is a completely separate context, even when I'm working on the same client project. I'm constantly asking: which device has the right context? Does it have the full project identity this session needs?

I've cobbled together workarounds: pushing projects to Dropbox, writing aggressively to memory, maintaining a private Git repo to carry state. It's brittle. Paths change between machines, Dropbox sync locations differ, and I spend more time managing Claude contexts than using Claude.

Root Cause

Memory is keyed on the absolute filesystem path — stored under ~/.claude/projects/<encoded-absolute-path>/memory/. Same project, different machine = different key if the username, mount point, or sync path differs. This is documented in #25739. The git remote URL — which would be a stable cross-device identifier — is not used.

What's Been Tried

• autoMemoryDirectory (shipped v2.1.74, March 12, 2026) lets you redirect memory storage to a custom path (e.g., Dropbox), but doesn't address the identity problem natively and breaks when sync paths differ.
• Community tools exist — claude-context-sync, claude-sync, user-memories (the last using git remote URL as key) — but these are evidence of demand, not a solution.
• claude.ai already has cloud-synced, account-bound memory. Claude Code does not. These two systems are disconnected despite sharing an Anthropic account.

The Ask

Basic: Native support for account-bound, shared project identity in Claude Code — context and memory tied to the user's Anthropic account rather than the local filesystem path. Opt-in per-project, not global by default.

Dream: Full context portability across the entire Claude surface — claude.ai, Claude Code, Claude Desktop — so a user's identity and project context follow them wherever they work.

Related Issues

• [FEATURE] Portable project memory across machines (multi-device workflow) #25739 — Portable project memory across machines (multi-device workflow) — OPEN
• Feature Request: Claude Code Should Access User's claude.ai Memory and Context #14228 — Claude Code should access user's claude.ai memory — OPEN
• Feature Request: Persistent Memory Between Claude Code Sessions #14227 — Persistent memory between Claude Code sessions — OPEN

[WhymustIhaveaname]

I built a plugin for this: claude-memory-manager. It adds a global memory layer (~/.claude/memory/) that lives outside the path-keyed project directories, so the same memories show up regardless of which project you open. Also has a Web UI for browsing and editing all memories (global + per-project), and an export/import feature for syncing across machines.

[iLeonelPerea]

Until this ships natively, I've been using Syncthing to sync the project folder (including CLAUDE.md, MEMORY.md, and a memory/ dir) between Mac and Windows over LAN. No cloud, no accounts. Works with both Claude Code and Cowork.

Key trick: add a rule in CLAUDE.md telling Claude to always write memory to memory/ inside the project — not just .auto-memory/. That way memory travels with the code.

Detailed setup: https://alebrije.io/blog/never-re-explain-sync-claude-memory-mac-windows/

[achiii800]

+1, and two framings I haven't seen elsewhere in this thread that might be worth weighing in scope discussions:

Continuity for users without persistent compute. The desktop-and-iPhone-and-laptops scenario in this issue assumes you have all those devices and they're all yours. There's also a class of users who'd benefit immediately from cross-device session continuity because they have less — students, anyone on a single shared device, anyone in a context where leaving a workstation running overnight isn't an option. Today, when they close the laptop, the session is gone in any practical sense — the JSONL is on disk, but loading it back means being at the same machine. Account-bound continuity makes Claude Code something they can think with while away from compute, and resume execution when they're back at a workstation. Not just a power-user multi-device convenience — a different shape of user accessing the workflow at all.

Asymmetry should be first-class, not a gap to bridge. A receiver without the originating filesystem (the phone, claude.ai on a different machine) should load the session in a read mode: full conversational and contextual history, but the tool surface is limited to non-mutating tools, or none. The model can ideate, suggest, draft, plan — it cannot Edit / Write / Bash against a filesystem it has no executor for. This isn't a limitation to fix; it's the property that makes cross-device continuity safe. Trying to bridge the FS turns this into a remote-execution problem, which is much harder and a security minefield. Conversational surface = full. Execution surface = empty. Reattach to the originating device restores the execution surface naturally.

Codec layer evidence. achiii800/claude-snap is a ~500-LOC pure-stdlib lossless codec for Claude Code session JSONLs (sha256 content-hash refs, byte-identical roundtrip, mutation-aware dedup, regression-tested on real sessions). It demonstrates the wire format is tractable in user space — what's missing is the account-scoped sync layer and the receiving-client ingestion path, both of which are Anthropic's to ship. Distinct from cctrace (transcriber) / claude-mem (summarizer, lossy by design) / claude-conversation-extractor (markdown dump) — claude-snap is the only one of these that roundtrips byte-for-byte.

Cross-referencing #31992 for the CLI-flag primitive that the UX layer in this issue would call into.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.