Memory is fragmented across Claude Code and Cowork for the same user/project

Open 💬 0 comments Opened Jun 28, 2026 by joedeely

Summary

A user working on the same project across both Claude Code and Cowork has two separate, non-synchronized memory stores. Behavioral learnings, preferences, and feedback written in one surface do not carry over to the other, forcing the user to re-teach the assistant depending on which surface they happen to open.

The problem in practice

  • Claude Code stores memory in ~/.claude/projects/<project>/memory/ (local files).
  • Cowork has its own memory context.
  • The user has worked around this by keeping a project-specific memory file inside the project itself (e.g. Operations/Cowork/COWORK_MEMORY.md) so both surfaces can read it — but this is a manual hack, and only the in-project file is shared. Surface-specific memory files (Code's memory/ directory) are invisible to Cowork and vice versa.
  • Result: collaboration improvements made in a Code session (preference tightening, workflow rules) are partially lost when the user switches to Cowork for the same project, and vice versa.

Expected behavior

For a given user working on a given project, memory and learned preferences should be unified across Anthropic surfaces (Claude Code, Cowork, claude.ai), or at minimum there should be a documented, supported shared-memory mechanism rather than users hand-rolling an in-repo file.

Why this matters

The user is actively trying to build a continually-improving collaboration. Fragmented memory directly undermines that: the assistant appears to "forget" lessons simply because the user switched surfaces, even though it's the same person, same project, same goals.

Environment

  • Surfaces: Claude Code (desktop app, macOS) + Cowork
  • Workaround in use: shared memory file committed inside the project repo
  • Related: #71937 (no self-generated learning signal), #71935 (memory rules not enforced at inference time)

View original on GitHub ↗