Claude Code Projects Shared Memory: What Every Thread Knows, and Where It Stops

In a Claude Code project, shared memory is a set of notes Claude keeps about the project as files, indexed by a MEMORY.md file. Every cloud thread in the project reads that index when it starts and opens the other files when it needs them, and any thread, or the project conversation, can add to it when you ask Claude to remember a requirement, a decision or a pitfall. It is shared between the threads of one project, which is the point: a correction you make once reaches the threads that start later. It is not shared with other people, other projects or other tools. A project belongs to one user.

What a Claude Code project is

Anthropic announced the redesign on September 17, 2026, in a post titled Projects redesigned: from folder to conversation↗ (opens in a new tab). A project is now one ongoing conversation with Claude acting as coordinator. You describe work, and Claude starts a thread for each task: a separate Claude Code session, usually in the cloud, working on its own branch and opening a pull request when the work calls for one. The announcement puts it plainly: every thread now adds to and draws from a shared memory.

The Claude Code documentation on Projects↗ (opens in a new tab) sets the boundaries. Projects are in public beta on Pro and Max plans and rolling out gradually; they are not available on Team or Enterprise plans yet. You use them at claude.ai/code, in the Code tab of the desktop app, or in the Claude mobile app, not in the terminal CLI, the VS Code extension or the JetBrains plugin. The word “project” already meant something else in the Claude app, and that naming trap is covered in Claude Projects vs Claude Code.

Three layers of standing context

Project memory is one of three things that carry context across threads, and knowing which is which decides where a fact should go.

• Project memory: notes Claude writes itself, such as requirements, decisions and pitfalls, stored as files with a MEMORY.md index. You add or remove entries by asking Claude in the project conversation or in any cloud thread, and you can read, edit and delete the files under Project settings, Memory.
• Project instructions: text you write, sent to each new thread and to Claude in the project conversation, up to 16,000 characters. Set under Project settings, Memory, Project instructions, or ask Claude to change them.
• The repositories themselves: every cloud thread clones the project’s repositories and reads the CLAUDE.md files and skills in them when it starts.

The documentation draws the line clearly: put instructions about a repository in its CLAUDE.md, and notes about the project in project memory. Rules you want worded exactly and applied to every thread from the start go in project instructions.

How the memory fills up

Much of it fills up without you asking. When you tell Claude how to run the project, for example “run at most two threads at a time” or “don’t open a pull request until I’ve seen the plan,” Claude saves the preference to project memory on its own and follows it in later cloud threads. The documentation adds a caution worth taking seriously: these are instructions Claude keeps to, not enforced settings, so a thread limit given this way is not a hard cap.

The rest comes from corrections. When you correct a thread, the documentation suggests also telling Claude to remember the correction, so it goes into project memory and later cloud threads start with it. Anthropic’s announcement gives the kind of fact this is for: that the release moved to Friday, why the export was dropped, or who to check in with before touching the billing service.

Project memory also does a second job. The project conversation does not replay its full history; it works from recent messages, recent threads and project memory, so it can keep going for as long as the project runs. The documentation’s advice follows from that: put anything that must never be dropped in project memory.

What it is separate from

Several Claude features use the word memory, and project memory is not any of the others.

• Claude Code’s auto memory↗ (opens in a new tab) on your own machine. Both use a MEMORY.md index, but they are separate stores. Cloud threads do not pick up anything from the Claude Code setup on your computer. Local auto memory is covered in Claude Code memory.
• The CLAUDE.md files in your repositories. Threads read them, but project memory is not written into them.
• Memory in Claude chat and in chat projects, which is a different system again. See Claude project memory.
• A thread you run on your own computer. When a task needs a local database or a tool only your machine has, Claude can run that thread there through Remote Control. The documentation says such a thread starts with the project’s instructions, but not with its memory files loaded.

That last point matters in practice. If a rule must reach every thread, local ones included, it belongs in project instructions rather than in memory alone.

Where shared memory stops

The documentation’s Limitations section is short and specific:

• A project belongs to one user. You cannot share a project or its threads with another user, and thread transcripts do not have the share option other cloud sessions have.
• There are no organization-level controls for projects during the beta.
• A thread belongs to the one project that started it. Threads cannot be moved or copied to another project, and two projects cannot be merged.
• Deleting a project permanently removes it along with its threads, its memory and its files. Branches and pull requests on GitHub are not affected.
• Threads use Anthropic as the model provider, and projects are not available through Amazon Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry.

“Shared” therefore means shared between your threads. A teammate cannot read what the project remembers, ChatGPT or Cursor cannot read it, and a second project of yours starts empty. For a team that wants several people giving Claude work in one place, the same page points to Claude Tag, which runs in Slack channels on Team and Enterprise plans.

Keeping project memory useful

• Write the brief first. The documentation recommends project instructions that say what the project is for, which branch to start from, how a thread checks its own work, what to do when something is missing, and what needs your go-ahead.
• Ask Claude to remember decisions as decisions: what was chosen and why, not only the outcome. A later thread that knows why the export was dropped will not quietly add it back.
• Read the memory files every week or so under Project settings, Memory. Delete what is stale; a wrong note is worse than a missing one, because every thread trusts it.
• Move anything that has hardened into a rule into project instructions, where you control the exact wording.

When the work outgrows one person and one app

If you work alone, entirely in Claude Code, on GitHub repositories, project memory may be all the shared memory you need, and it is built in. Stay with it. The gaps show when other people need to see the state of the work, when you also plan in ChatGPT or code in Cursor, or when you start a second project and want the same rules.

fenbs fills that gap from outside. It is a web app where projects, tasks, decisions and rules, lessons learned and where you left off sit on one kanban board that people and AI apps share over MCP. Cloud threads in a Claude Code project start with the connectors on your claude.ai account, so once fenbs is added there as a custom connector (the steps are on the Claude integration page), a line in project instructions can point every thread at the board:

- At the start of every thread, call fenbs_get_context for this project and follow its Rules.
- Work from the board: if a task is not on it, create it first.
- When you finish or stop, call fenbs_save_progress with where each task stands.

The board then holds what should outlive the project and be visible to others: rules on the Decisions and rules page, written by people and followed by every assistant; Where we left off for each project; and History, which records every change and who made it, a person or which assistant. Assistants cannot sign off decisions or pre-approve work. fenbs does not run threads, open pull requests or replace project memory for the details only Claude needs.