Feature Request: Claude Code Should Access User's claude.ai Memory and Context
Problem
Claude Code and claude.ai are completely disconnected experiences despite being the same user, same subscription, same "Claude." The claude.ai Claude knows the user. The Claude Code Claude is a stranger.
The Disconnect
claude.ai knows:
- User's name, preferences, communication style
- Projects discussed over months of conversation
- Technical stack, coding conventions, architectural decisions
- Personal context shared over time
- The relationship built through hundreds of conversations
Claude Code knows:
- Whatever is in CLAUDE.md
- Nothing else
Same User, Different Claudes
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. This is not a unified product experience.
The Ask
Claude Code should have access to the same memory/context system as claude.ai.
If claude.ai knows:
- My projects and their architecture
- My preferences for code style
- My technical background
- Context from past conversations
Then Claude Code should know these things too.
Implementation Options
Option A: Read-Only Memory Sync
- Claude Code pulls from claude.ai's memory at session start
- User context is available without manual CLAUDE.md maintenance
- Memory is managed in claude.ai, consumed in Claude Code
Option B: Bidirectional Sync
- Claude Code can also contribute to memory
- Learnings from CLI sessions inform web sessions
- Unified memory across all interfaces
Option C: Shared Memory API
- Internal API that both products use
- Single source of truth for user context
- Any Claude interface gets the full picture
Why This Matters
The promise of Claude is an AI that understands you and your work. That promise is broken when different interfaces have different levels of understanding.
Users shouldn't have to choose between:
- Good interface (Claude Code) + no memory
- Bad interface (claude.ai web) + memory
We should get both.
Alternatively, if these fixes are not feasible in the short term, update your ToS to allow subscribers to access their own sessions programmatically. This would let users build tools that work while these issues are addressed. Paying $200/mo for a product we can't reliably use, with no workaround permitted, is not acceptable.
Found 3 possible duplicate issues:
- https://github.com/anthropics/claude-code/issues/13843
- https://github.com/anthropics/claude-code/issues/12858
- 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.