THE SIGNAL BRIEF
AGENTS · HARNESS · CLAUDE-CODE · MEMORY · SERIES

Multiplayer Claude Code Projects: what is public, and what is already inside

November 8, 2026

This is a special issue of the Inside Claude series. It did not wait for its turn because a lot of people are asking the same question right now.

A post on X said Anthropic is working on a collaborative mode for Claude Code Projects.1 The replies were full of good questions. Will two people's sessions touch the same files? Who wins when two people approve different things in one thread? What happens when a few people edit the same instructions, and nobody deletes the stale lines? And mine: will a shared project share memory and decision history between people, or just the threads? For a team, that is what decides whether it is usable.

I looked at two things. What Anthropic has published, and what Claude Code itself already contains, read from the inside the way this series reads everything. Here is what each says.

What a project is today, in public

A project is "one coordinating conversation with Claude plus the threads it starts to do the work".2 The conversation is the coordinator. Each thread is a separate cloud session, on its own branch, that reports back when it is done. The coordinator "sees what threads report back, not every step they take".3

And today, a project has exactly one person in it. The docs say it twice, without hedging:

"A project is yours alone: you're the only one who sends it work or sees its threads, and it uses your own GitHub access and connectors."4

"A project belongs to one user. You can't share a project or its threads with another user, and thread transcripts don't have the share option other cloud sessions have. There are no organization-level controls for projects during the beta."5

Team and Enterprise plans do not have Projects yet. The announcement says they "come after that".6 So every answer below is about a product that, today, is single-player.

What the public sources already answer

Several questions from the thread have a public answer, because they are already true between the threads of one person's project.

Two sessions touching the same files. Each thread works "on its own branch and copy of the repo", and "if any threads work on the same code, the overlap is resolved as a merge conflict just like any other PR."7 No new locking, no live co-editing. Git is the arbiter. A thread card even has a Resolve conflicts button.8

Approvals. An approval lives inside one thread: "When a thread needs your approval, the prompt is inside that thread and the thread waits until you answer it there. Telling Claude in the project conversation to go ahead doesn't reach it."9 So with two people, the question would not be "who wins in the project", but "who may answer a prompt inside a thread". The docs do not say, because there is only one person who can.

Decision history. This is the part that surprised me. There is no decision log, but decisions have a home: project memory holds "requirements, decisions, and pitfalls, stored as files", and "Every cloud thread reads the index file MEMORY.md when it starts".10 The conversation itself does not keep its history: it "works from recent messages, recent threads, and project memory rather than its full history".11 The announcement gives the kind of thing it remembers: "the release moved to Friday, why the export was dropped, or who to check in with before touching the billing service."12

So the honest answer to my own question, for today, is: the history of decisions is whatever got written into project memory. The rest lives in thread transcripts, which only the owner can open.

Stale instructions. Project instructions and memory are not the same thing. Instructions are up to 16,000 characters sent to every new thread.13 Preferences Claude saves to memory are "instructions Claude keeps to, not enforced settings".14 And settings changes "reach new threads, not threads already running".15 So the "loudest paragraph" problem one reply described is real even with one person: an old memory file keeps steering new threads until someone deletes it in Project settings > Memory.

What is already inside

Claude Code's memory instructions, the text the model reads when it decides what to remember, already sort every memory into a scope: private or team.16

Memory type Scope written into the instructions
user (your role, your preferences) "always private"
feedback (your corrections) "default to private. Save as team only when the guidance is clearly a project-wide convention that every contributor should follow"
project (work, goals, bugs, incidents) "private or team, but strongly bias toward team"
reference (where to find things) "usually team"

That table is the answer a team would want. Your style stays yours. A project fact, which is where decisions go, leans shared. A correction you give becomes a team rule only when it is a convention for everyone, not a taste.

Inside, there is also an organization memory with its own access logic. Its events speak of a connection that can be on, parked or off, of read and write settings that change, of a write access that has to be requested and that can be withdrawn, and of switching between projects.17 I first read the word "decision" in those events as a decision log. It is not. In the code, the "decision" is whether this session is connected to that memory, and with or without the right to write. That is a permission model, and a permission model is what you build before several people write into the same place.

Two more details point the same way. When a chat's project changes, or the chat is moved out of its project, the harness re-reads its context rather than keep the old one.18 And the project's coordinator session has tool descriptions that speak of uploads "on a person's message in this project".19

What nobody can see yet

  • How two people's memory writes are merged. Nothing inside resolves two people writing the same memory file at once. Server side, maybe; not visible.
  • Who answers a thread's prompts when two people can see it.
  • What "Recent activity" counts. The Projects page in the X post shows it with an internal-only label. I found nothing that defines it.
  • When. The pieces above are plumbing. Plumbing says what is being built, not when it ships, or whether it ships in this form.

So, threads only, or memory too?

Public, today: neither is shared between people. Memory is shared between threads, not between people, and a project has one person.

Inside: the memory layer is already built for more than one person. Scopes decide what stays private and what goes to the team, and an access model decides who reads and who writes. If a shared mode ships on top of that, it would share memory, with personal notes kept out by design, and decisions would be shared only if someone asked Claude to remember them.

That last part is the one to watch. A team whose decisions live in thread transcripts will not get them back from a shared project. A team that says "remember that we decided X" will.

Sources

  1. TestingCatalog on X, November 7, 2026, as recorded in research/claude-projects/README.md, first paragraph. ↩
  2. research/claude-projects/public/claude-projects-docs.md, line 52 (Claude Code docs, "Let Claude coordinate ongoing work with Projects", fetched 2026-11-08). ↩
  3. research/claude-projects/public/claude-projects-docs.md, line 54. ↩
  4. research/claude-projects/public/claude-projects-docs.md, line 436. ↩
  5. research/claude-projects/public/claude-projects-docs.md, line 454. ↩
  6. research/claude-projects/public/projects-redesigned.md (Anthropic, "Projects redesigned", September 17, 2026). ↩
  7. research/claude-projects/public/projects-redesigned.md. ↩
  8. research/claude-projects/public/claude-projects-docs.md, line 186. ↩
  9. research/claude-projects/public/claude-projects-docs.md, line 250. ↩
  10. research/claude-projects/public/claude-projects-docs.md, line 292. ↩
  11. research/claude-projects/public/claude-projects-docs.md, line 231. ↩
  12. research/claude-projects/public/projects-redesigned.md. ↩
  13. research/claude-projects/public/claude-projects-docs.md, line 293. ↩
  14. research/claude-projects/public/claude-projects-docs.md, line 246. ↩
  15. research/claude-projects/public/claude-projects-docs.md, line 379. ↩
  16. research/claude-projects/README.md, section "Org memory, seen from the inside", memory type scopes. ↩
  17. research/claude-projects/README.md, section "Org memory, seen from the inside", telemetry family and excerpt. ↩
  18. research/claude-projects/README.md, section "Org memory, seen from the inside", context re-read triggers. ↩
  19. research/claude-projects/README.md, section "In this session's tool descriptions". ↩