Feature Request: Sync memory between Claude Code and claude.ai

Resolved 💬 2 comments Opened Apr 13, 2026 by lumihelia Closed May 25, 2026

Problem

I use both Claude Code (CLI/desktop) and claude.ai for different parts of my workflow. Over time, Claude learns important context about me — my role, my projects, my preferences, my ongoing work — through the memory system.

But these memories are completely siloed. Claude Code's project memory (~/.claude/projects/) and claude.ai's memory are two separate systems that don't talk to each other.

This means:

  • Deep context built in one environment is invisible in the other
  • I have to re-explain who I am and what I'm working on when switching between them
  • Long-running projects that span both environments lose continuity

Example

In Claude Code, I've been building a learning system for a career transition project over multiple sessions. Claude remembers my goals, my aesthetic preferences, key decisions I've made, and where I left off. If I switch to claude.ai to continue thinking about the same project, none of that context exists — I'm starting from scratch.

Proposed Solution

Some form of memory sync or shared memory layer between Claude Code and claude.ai, so that user-level memories (who I am, how I work, what I care about) persist across environments.

This doesn't need to be automatic or full-sync — even a manual "export/import" or a shared memory namespace would be a significant improvement.

Why This Matters

For users who treat Claude as a long-term collaborator (not just a tool for one-off tasks), continuity of context is everything. The current siloed memory creates a fragmented experience that undermines the value of memory itself.

Additional Question: Why are they separate in the first place?

I initially assumed this was a privacy concern — Claude Code runs locally, so memory stays on-device. But Claude Code also works on mobile and as a web app (claude.ai/code), which means it's not purely a local tool anymore.

If Claude Code can already operate in the cloud, the "local-only privacy" argument for keeping memories separate doesn't fully hold. So what is the actual architectural or product reason for the separation?

Even if full sync isn't feasible, a user-controlled bridge (e.g., opt-in sync of user-level memories, while keeping project-level memories local) would respect both privacy and continuity.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗