Can Claude Projects Reference Each Other?

No — not in the way people usually mean. A chat in one Claude project cannot open another project’s knowledge files, search its chats or draw on its memory. Anthropic’s help centre describes each boundary explicitly: chat search stops at the project’s edge, memory is kept per project, and knowledge is used by the chats inside that project. It does not describe any setting that lets one chat project read another. The one documented bridge is in Cowork, where a project can link a chat project as context. Everything else is a workaround, and the good ones keep a single copy of the shared material somewhere both projects can reach.

What the help centre says, boundary by boundary

Anthropic’s overview of what projects are↗ (opens in a new tab) calls them self-contained workspaces with their own chat histories and knowledge bases. The more specific pages fill in what “self-contained” means for each thing a project holds.

• Knowledge. Anything you upload to a project’s knowledge is used across the chats within that project. Nothing in the help pages describes a way to point it at another project’s files.
• Chats. The page on creating and managing projects↗ (opens in a new tab) goes further: context is not shared across chats even within one project unless the information is added to the project knowledge. If sibling chats cannot see each other, chats in a different project certainly cannot.
• Chat search. The article on chat search and memory↗ (opens in a new tab) lists the two places Claude can search: all chats outside projects, and individual project conversations, with searches limited to within each specific project.
• Memory. The same article says each project has its own separate memory space and project summary, separate from other projects and from chats outside projects. A preference Claude learned in project A does not follow you into project B.

Where the documentation is silent — for example, on whether Claude might ever pull in another project’s knowledge through some other route — the safe reading is that it does not. Plan as though each project knows only what you put in it.

Why the walls are there

The separation is the point of a project, not an oversight. A consultant with one project per client needs certainty that client A’s contract terms never surface in a draft for client B. On Team and Enterprise plans, projects also carry their own sharing: a colleague with Can view on one project has no business reading the knowledge of another they were never invited to. A project that could quietly reach into its neighbours would break both promises.

So the question to ask is narrower than “how do I connect my projects?” It is “which material is genuinely shared, and where should the one copy of it live?”

The documented bridge: Cowork projects

Cowork is the one place Anthropic documents a link between projects. The help page on projects in Claude Cowork↗ (opens in a new tab) lists a project’s context as a local folder, a linked chat project, or a URL for Claude to reference. It also offers “Import from project” when you create a Cowork project, which transfers the files and instructions from one existing chat project; bulk import is not supported.

Two cautions. Importing is a transfer at a point in time, so later edits to the original are not described as flowing across. And memory is still scoped: the same page says what Claude learns in one Cowork project does not carry over to others. How projects behave on each surface is covered in Claude Projects in chat vs Cowork.

Four ways to share material between projects

1. One shared file, uploaded to each project

The simplest route: keep a master copy of the shared material — the style guide, the product glossary, the company background — outside Claude, and upload it to each project that needs it. Put the date in the file name, such as style-guide-2026-09.md, so a stale copy is obvious at a glance.

• Works on every plan, with no set-up.
• The cost is drift. Upload the same file to five projects and you have five copies to replace when it changes. Keep a list of which projects hold it.
• Reference the file by name in each project’s instructions, so Claude knows it is the source of truth there. Claude Projects best practices covers writing those instructions.

2. A connector to the shared source

If the shared material already lives in a document store or a tool, connect Claude to that instead of uploading copies. A connector reads from the source when a chat needs it, so every project that enables it sees the current version. Anthropic’s page on using connectors↗ (opens in a new tab) says Claude inherits each person’s permissions from the connected service, so it can only reach what the person chatting could reach anyway.

The same page notes that on Team and Enterprise plans connectors are only available in private projects, and each person authenticates individually. A shared team project therefore cannot lean on a connector for everyone. What connectors can reach, and how admins restrict them, is in Claude connectors explained.

3. A written hand-off between projects

When one project produces something another needs — a decision, a finding, a revised definition — end the chat by asking Claude to write it up in a few lines, then add that note to the other project’s knowledge. It is manual, but it is deliberate: only conclusions cross the wall, never a whole conversation. Moving a chat is the other manual option; the dropdown next to a chat name moves it between projects, and where memory is on, that also changes which project’s memory it feeds.

4. A board both projects read

When the shared thing is not reference material but work — what is open, who is on it, what was decided — the right home is a board that every project can reach through the same connector. The board holds one copy; each project’s chats read it and write to it; nothing is duplicated.

How this looks on a fenbs board

On fenbs, one board can hold several projects, and its AI context has two layers: notes that apply to everything on the board, and notes for one project. Connect Claude once with the Claude connector, and a chat in any of your Claude projects can ask for both layers.

## Shared context
- Before answering about ongoing work, call fenbs_get_context with project "Website".
  That returns the board-wide notes plus the notes for this project.
- Tasks for this work are in project "Website"; use fenbs_list_items with that project.
- Record decisions with fenbs_add_decision, never in this chat alone.

A second Claude project, say for the mobile app, uses the same lines with project "Mobile app". Both see the board-wide notes — the house style, the release rules — from one copy; each sees only its own project’s notes and tasks. When Claude learns something every project needs, it writes one context note without a project, and the next chat in any project reads it. Every change is recorded as “Claude via” the person who connected it, which is more than a knowledge file can tell you.