Feature Request: Claude Code Should Access User's claude.ai Memory and Context

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/13843
2. https://github.com/anthropics/claude-code/issues/12858
3. https://github.com/anthropics/claude-code/issues/14227

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

Please, take a look at this, it really works for me, in case anyone look, I would love to hear some feedback.
memory-ts
Only three commands, the first time, then one single command and use Claude Code normally. The memory system is fully autonomous, no overhead for the user or for Claude, no tools, no slash command, nothing. All memories are saved in markdown format, git and grep search compatible and can be edited using any text editor, the embeddings are auto updated when this happens. It uses a new database kind that for the 10 - 20 K records has a competitive performance (better in some cases) with the giants in the field, but all records are human readable markdown files.
No context bloating, no dumping everything when the session start. Only a very brief last session summary and project snapshot. Then, for each message sent the memory system searches for relevant memories to the context of that single message and inject's into the prompt if any, the whole process takes less than ~150ms. Everything is local, just need to run a bun http server and it serves for all concurrent sessions in the same or different projects. Not a single command, tool or intervention from both Claude or the user. The memories are extracted at the end of each session or before context compression by resuming the session in the background. The whole cost of the memory system is only one extra message per session. For retrieval it uses a 10 dimensional algorithm with relevance gatekeeping mechanism. The retrieval is ultra fast because of the work Claude does when extracting the memories with a rich set of metadata used at the retrieval moment.

The memories are auto organized par project, concurrent sessions in the same project can access all memories. It really worth be looked at. In case you want to skip looking at the repository, to try is just:
bun install -g @rlabs-inc/memory
memory install (install Claude Code hooks)
memory serve
Then use Claude Code as usual. Nothing else to learn about it.

Fully editable and totally invisible. Give it a try and let me know what you think.

Complete agree on this feature, we need a way to keep context between web and terminal in some way memory to be shared or reused. Would be even nice initially to have a session Id we can refer in web from our machine.

Found this project which might help to bridge the problem.

https://github.com/BioInfo/continuum
https://rundatarun.io/p/i-built-a-personal-memory-system

This would be a fantastic quality of life feature. I use Claude Code and the web app constantly, and the lack of shared memory is frustrating. Claude knows my preferences and project context from months of web conversations, but the moment I open Claude Code, I'm starting from scratch.

With Cowork now in the mix, this issue affects the entire product suite. Whether someone uses Chat -> Cowork -> Code or just bounces between Chat and Code like I do, the context should follow. Right now every tool feels disconnected despite being part of the same subscription.

Totally agree with this. The disconnect between Claude Code's local context and your claude.ai memories/projects is a real pain point.

While we wait for Anthropic to bridge this gap natively, one workaround I've been using is claude-brain — it keeps your entire Claude Code brain (CLAUDE.md files, settings, agents, skills) version-controlled and synced via git hooks. So at least your local Claude Code context travels with you across machines.

Would love to see Anthropic eventually unify the memory/context layer across all their surfaces though. That would be a game-changer.

This disconnect is why we built GrantAi Brain — a unified memory layer that works across Claude Code, Claude Desktop, and any MCP-compatible client.

Full context recall from 2 minutes ago to 5 years ago. 12ms retrieval. Your preferences, project architecture, coding conventions, past decisions — all instantly available in every session, regardless of which interface you use.

100% local storage, AES-256 encrypted, zero cloud dependency. One brain, every Claude.

https://solonai.com/grantai

I'm paying for ONE Claude. I should get ONE Claude. When I talk to Claude on the web, it knows me. When I open Claude Code, it's like meeting a stranger who happens to have the same name.

The one and only Claude himself brought me to this PR using that phrase

I also need this feature. I use the Claude mobile app for technical discussions during spare moments, and once my thoughts are organized and I have a
dedicated block of time, I switch to Claude Code. In this workflow, correctly transferring the prior context to Claude Code every time is painful. Even if it
requires an explicit instruction like "look at the content of chat session XXX," I need some kind of bridge between the two.

This is definitely worth looking into:
Adding a broader framing: this is a multi-surface problem, not just a two-surface one

The disconnect described above is real, but I think it understates the actual scope of the problem. The modern Claude user doesn't just operate across two surfaces. They operate across four or more (I definitely do this):

claude.ai (web)
Claude Desktop (native app)
Claude mobile (iOS/Android)
Claude Code (CLI)
Claude Code in the IDE (VS Code, JetBrains, etc.)
And critically, these surfaces serve fundamentally different moments in a developer's day:

Mobile is where ideation and architecture discussions happen, on the commute, between meetings, away from the desk
claude.ai / Desktop is where deep thinking, research, and long-form reasoning happens
Claude Code is where implementation happens
Right now, each of these is a memory island. A developer who thinks through an architectural decision on mobile, refines it in a claude.ai thread, and then opens Claude Code to implement it has to re-establish all of that context from scratch. The friction isn't just inconvenient. It breaks the compounding value that a persistent AI relationship is supposed to deliver.

The real ask is unified user identity across all surfaces, not just a Code to Web sync.

A phased approach that would actually solve this:

Phase 1: Account-level memory in Claude Code: Move beyond per-project local files to a proper account-scoped memory layer, analogous to what claude.ai already has. This is independently valuable even without cross-surface sync.

Phase 2: Cross-surface sync as an opt-in toggle: Once account-level memory exists in Claude Code, expose a settings toggle to sync with the shared account memory layer. All Claude surfaces read from and write to the same user model. Opt-in by default to avoid privacy concerns for users who don't want it.

This builds on infrastructure that already exists, is phased so Phase 1 ships real value fast, and keeps users in control of what crosses surface boundaries.
:)

PS: Not looking for workarounds but a native feature that should work seamlessly.

@bcherny Worth your attention. thanks 🙏

Adding a perspective from a non-technical user who uses Claude Code as a long-term collaborator (not just a coding tool):

The privacy argument for keeping memories separate doesn't hold anymore.

Claude Code is no longer a purely local tool — it runs on the web (claude.ai/code), on desktop, and in IDEs. If it can already operate in the cloud, "local-only privacy" isn't a valid reason for siloed memory.

The solution is simple: give users the choice.

• Let the user decide whether their claude.ai conversations and memory can sync with Claude Code (and vice versa)
• Make it opt-in, with granular control (e.g., sync user-level memory but keep project-level memory local)
• If the user says yes → full continuity. If the user says no → nothing changes.

This turns the privacy concern from a blocker into a checkbox. The choice belongs to the user, not to the product team making a blanket decision on their behalf.

Related: #47299 (our issue exploring this from a similar angle)

+1, with a note on scope.

This is framed in the thread as a developer-experience issue, but it's structurally worse for users on non-keyboard input. I use eye-gaze input exclusively and rely heavily on Claude.ai Memory as daily context. Every alternative interface I might move to — voice, wearables, BCI — restarts from zero because Memory is UI-locked.

The fix is the same for everyone. No separate accessibility feature needed; just don't lock the general feature to one surface.

Three tiers, minimum to ideal:

1. Programmatic Memory Export API — automate the existing manual export from settings
2. Read-only Memory Access API — authenticated self-read for use in own applications
3. OAuth scope — user-authorized third-party access, analogous to Google OAuth scopes for Gmail/Calendar

Tier 1 alone would already be a meaningful step, since it just exposes an existing user right through an API surface.

Also submitted to privacy@anthropic.com as a data portability request. Full proposal available on request.

— JaH

The same memory split exists between Cowork and chat (web + mobile). Wherever the user opens Claude, the underlying memory should be the same coherent layer. Filed a broader issue at #55842 framing memory and three other surfaces (files, skills/connectors, handoff) as a single unified-state problem.

It would be huge for claude code to have access to claude chat memory.
Note: one next step to think of as well is having claude chat access claude code memory.
Structurally more complicated because local memory has to make it to claude chat remote account memory.

+1 on this. I'd like to add a concrete angle that hasn't been raised yet: device fragmentation makes this worse than a simple "Code vs claude.ai" split.

I currently use Claude across a desktop PC, a laptop, and claude.ai chat — and I'm planning to add more devices. Each Claude Code install has its own local ~/.claude/ config (CLAUDE.md, settings.json), so even within Claude Code alone, my setup diverges across machines unless I manually sync files (Git + symlinks, cloud storage, etc.). Add claude.ai's account-level Chat Memory on top, and I now have N+1 separate "versions" of Claude to keep in sync, where N = number of devices.

A phased approach would help a lot:

1. Read-only: Claude Code fetches claude.ai account memory at session start (no need for permanent cloud storage of Code's local settings — just a check on launch).
2. Opt-in sync of Claude Code's own learnings back to claude.ai memory.

Even just phase 1, exposed as an opt-in setting, would remove most of the "stranger" feeling described above — and it would scale to however many devices/surfaces a user has, since the source of truth would be the account, not any one machine.

One more request while I'm here: an automatic Chat/Code routing feature that learns from a user's interaction patterns and decides which surface to use, without the user manually choosing each time. I think this would benefit users on two fronts:

• Latency: simple conversational questions could be answered directly by the lighter-weight Chat surface, instead of going through Code's tool-calling loop (file search, command execution, etc.) unnecessarily.
• Cost: Code's agentic loop typically involves multiple tool calls and additional API round-trips per turn. Routing simple questions through Code by default risks consuming more tokens/usage quota than needed.

This would also reduce the cognitive overhead of the user having to decide "should I ask this in Chat or open Code?" every time.

One angle I haven't seen made explicitly here: the third-party memory ecosystem that has grown around this gap is itself the strongest argument for the feature. And the subset of it that actually bridges surfaces makes the privacy situation worse, not better.

My split is the one described upthread. Product and architecture thinking happens in claude.ai, where Claude has months of context on what I'm building and why. Implementation happens in Claude Code, where it has a CLAUDE.md and whatever auto memory has picked up about that one repo. Same person, same project, same subscription, same day, and I re-explain the reasoning every time I move between them.

CLAUDE.md helps but it only carries what I remember to write down, and the decisions worth carrying are usually the ones I didn't think to. That points at something I think is missing from both memory systems, not just the sync between them. What they capture today is state: my stack, my conventions, the build command that actually works. What they don't capture is intent. Why this project exists, what I decided against and for what reason, what I'm optimizing for right now, which constraints are real and which ones I'm choosing. That's the layer that actually needs to cross surfaces, because intent is formed in conversation and spent in the terminal. Claude Code doesn't need to know that I discussed pricing on the web last week. It needs to know that a decision was made and what it was made against, so it stops re-litigating it or quietly building something that contradicts it.

So the practical options for someone who wants continuity today are: maintain the bridge by hand, or reach for one of the third-party memory layers. And this is where it gets uncomfortable. The local-first ones (memory-ts above, OpenMemory) can't bridge surfaces at all: connecting claude.ai means registering a custom connector, which means a network-reachable endpoint. So anything that actually solves the cross-surface problem today has to be hosted somewhere, and that somewhere isn't my machine and isn't Anthropic. Point Mem0 or Basic Memory at both surfaces and it works, at the cost of my accumulated project context and working preferences living on a third party's infrastructure.

That's the part worth sitting with. If the rationale for keeping the two systems separate is that Claude Code memory is local and shouldn't leave the machine, notice what the current design actually achieves. It doesn't prevent context from being centralised. It just guarantees that when it is, Anthropic isn't the one holding it. A user-controlled opt-in sync would be a strictly better privacy outcome than the status quo.

I'd second the phased proposal above: account-level memory in Claude Code first, then an opt-in sync toggle. The scoping distinction is worth getting right. User-level context (stack, conventions, intent, how I work) is what benefits from crossing surfaces. Project-level auto memory (build commands, debugging notes for one repo) should stay local. Merging those indiscriminately would degrade both. But that's a design detail, not a blocker.