pavel 1ar.ionov
Contact

How Claude Cowork handles CLAUDE.md memory

Digging into Claude Desktop's Cowork filesystem to understand how it manages CLAUDE.md across sessions

I tried to figure out what Claude Cowork picks as a global (user) CLAUDE.md and it took me way longer than it should have.

If you use Claude Code, you know the drill - ~/.claude/CLAUDE.md for global instructions, project-level CLAUDE.md for repo-specific ones. Clean hierarchy, predictable behavior.

Cowork is different. It runs inside a sandboxed Linux VM, and it has its own memory system that doesn’t share anything with Claude Code’s ~/.claude/CLAUDE.md.

Disclaimer: this is what I figured out by grepping around the filesystem and switching sessions back and forth. Anthropic’s docs don’t explain the internals. Take this with a grain of salt and let me know if I got something wrong.

Project Cowork CLAUDE.md

When you work in a folder, whatever CLAUDE.md is in that folder is automatically pulled into the context. Same as Claude Code - nothing surprising here.

Global Cowork instructions

Important distinction: Cowork instructions are not the same as personal preferences from Settings > General. Cowork has its own instructions that live in Settings > Cowork > Global Instructions. This is the stable base - always loaded, never overwritten by sessions.

Where global Cowork CLAUDE.md lives locally

There’s a shared file on the host filesystem:

~/Library/Application Support/Claude/
  local-agent-mode-sessions/{session_id}/{another_id}/memory/CLAUDE.md

This is not inside the VM (that disk image lives at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img). It’s a regular file on your Mac.

How sessions interact with this file

This is where it gets confusing.

  • Every new session copies this particular file on start
  • A session can create an internal copy of that file, which syncs changes back on write to the global file - but not to the Cowork instructions in Settings
  • When you switch to a different session, it overwrites the shared file with its own version
  • So if you switch back to an older session, it rolls back the “global” memory to that session’s snapshot
  • Creating a new session after that inherits the rolled-back version

Last-writer-wins, no versioning, no merge. Every session switch is a potential rollback of everything you taught it.

Keep in mind: this file is not back-propagated to Claude Cowork global settings in the app - those are immutable from the Cowork container’s environment. But Cowork very much can and will read the temp clone of those instructions, alter them, and a new session will pick those up.

On my machine, only 4 of 14 sessions even had a CLAUDE.md copy. The other 10 never triggered a read or write of the file. So not every session participates - only the ones where Claude actually touches memory.

Check it yourself

You can reproduce this pretty easily:

  1. Add a recognizable line in your global Cowork instructions from Settings
  2. Create a new Cowork session
  3. Ask Claude to change that line to UPDATE_1
  4. Create a new session
  5. Ask Claude to read the line - it should contain UPDATE_1
  6. Ask Claude to change it to UPDATE_2
  7. Switch back to the previous session
  8. Ask Claude to read the line - it should contain UPDATE_1 again
  9. Create a new session
  10. Ask Claude to read the line - it should contain UPDATE_1 again

Your UPDATE_2 is now a local change, isolated in a single session. Good luck finding it.

How to keep your sanity

Best thing I can say: don’t ask Claude Cowork to update the global memory file. Maybe even hardcode this into your instructions so it doesn’t try on its own.

Instead, change the project’s CLAUDE.md - the one in your working folder. That one behaves predictably and doesn’t get caught in the session-switching crossfire.

For anything that needs to persist across all sessions - put it in Settings > Cowork > Global Instructions. That’s the only layer that’s truly stable.

This isn’t documented anywhere I could find. I figured it out by grepping through ~/Library/Application Support/Claude/ and comparing file hashes across sessions. Hopefully Anthropic cleans this up at some point - a proper persistent memory layer that doesn’t get clobbered every time you switch tabs would be nice.