-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Description
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.