How to Share Context Between Claude Projects (4 Ways)

Claude Projects work well as long as a piece of work fits neatly inside one of them. The trouble starts when it does not. You have a Project for a client, another for your own writing, and a third for a codebase, and a decision you made in one of them matters in the other two. Or you split a large Project in half because it became unwieldy, and now each half is missing things the other knows.

The natural question is how to get Claude in one Project to know what was established in another. The short answer is that Projects are designed as separate containers, and nothing about putting two Projects in the same account joins them up. The longer answer is that sharing context between them is entirely achievable, as long as you treat it as a document problem rather than a memory problem. This post explains where the boundary sits, what does and does not cross it, and four patterns that work.

Why Projects Do Not Share With Each Other

A Project bundles three things: instructions that apply to every chat inside it, documents you attach as project knowledge, and the chats you have in it. All three are scoped to that Project. That scoping is the feature. It is what stops your client's terminology leaking into your personal writing, and what stops a coding Project's conventions turning up in a cover letter.

The same scoping is why a chat inside one Project has no view of another Project's instructions, documents or conversations. The question of what a Project shares even within itself is covered in Does Claude Remember Other Chats in the Same Project?, and the short version is: materials, yes; previous conversations, not as transcripts. Across Projects, not even the materials are shared.

There is one complication. Claude has had account-level memory capabilities whose availability, scope and names have varied by plan and over time. Whether any of them reaches across Project boundaries in your account is something to verify rather than assume, because published descriptions have changed and will change again. A quick test is described further down. The overview of what Claude retains by design is in What Claude AI Actually Remembers.

For planning purposes, the safe assumption is that Projects do not share context with each other, and that anything you want in more than one Project has to be put there.

What You Actually Want to Share

Before choosing a method, it helps to be specific about what needs to cross. In practice it falls into a handful of categories, and they behave differently.

Stable facts about you. Your role, how you like answers formatted, the tools you use, the language you write in. These rarely change and apply almost everywhere.

Decisions. Things you settled in one Project that constrain another: a naming convention, a chosen approach, a rejected option and the reason it was rejected.

Current state. Where a piece of work stands today. This changes often and goes stale quickly.

Reference material. Documents, specifications, glossaries. Usually large, and only partly relevant to any given question.

The common mistake is to treat all four the same way, typically by copying everything everywhere. That produces Projects full of duplicated, slowly diverging material, which is worse than having nothing, because the model will draw on whichever copy it happens to find.

Pattern 1: A Shared Core Brief

For stable facts about you, the simplest reliable approach is a short "core brief" that you keep in one place and copy into each Project's instructions.

Keep it short, ideally under a page. It should contain:

• Who you are and what you do, in two or three sentences.
• How you want answers: length, format, tone, anything you always have to correct.
• Tools, languages and conventions you use everywhere.
• Hard rules: things that should never happen regardless of Project.

Put it at the top of each Project's instructions, followed by the instructions specific to that Project. Instructions are supplied at the start of every conversation in the Project, so this material is applied consistently rather than retrieved when something matches.

The catch is maintenance. When the brief changes, you need to update it in every Project that uses it. Keep the master copy outside Claude, in a plain text file or a note, date it, and make updating each Project part of the change. If you have more than a handful of Projects, keep a list of which ones carry the brief.

Pattern 2: A Decision Log That Travels

Decisions are the category most worth sharing and the easiest to lose. A decision made in one Project that affects another is precisely the thing that will be re-litigated if the second Project does not know about it.

Keep a decision log as a single document: reverse-chronological, one short entry per decision, with the date, what was decided, what was ruled out and the reason. Two or three lines per entry is plenty. Attach it as project knowledge in each Project it affects.

A few practical points:

• Write entries in the vocabulary you will use when asking. Attached documents are drawn on selectively, and a decision recorded in different words from your later question is easier to miss.
• Promote the critical ones into instructions. If a decision must always apply, put a one-line version in the instructions of each affected Project as well, because instructions are supplied unconditionally and attachments are not.
• Prune entries that no longer matter. A log that grows without limit becomes reference material, and its useful entries get harder to find.

At the end of a working session in any Project, ask Claude for a short list of what was decided and what was ruled out, check it, and add it to the log. Then re-attach the updated log wherever it lives. This is the single habit that does the most to make separate Projects behave as though they share a history.

Pattern 3: A Handover Message for Current State

Current state changes too often to keep in instructions or attachments without constant editing. For this, a handover message at the start of a chat is usually better than anything stored in the Project.

When you move from working in one Project to working in another, and the second needs to know where the first stands, write a short handover:

1. What this is about, in one sentence.
2. Where it stands, in two or three lines.
3. What was decided recently that matters here.
4. What is still open.

Paste it as the first message of the new chat. This is the same technique used for continuing a long conversation in a fresh chat, described in Continue a Long Claude Chat in a New Conversation. The only difference is that the source and destination are in different Projects.

Before doing real work, ask Claude to restate the constraints and open questions from the handover. If it gets them right, carry on. If not, fix the handover now.

Pattern 4: Merge or Split Deliberately

Sometimes the right answer is not to share context between two Projects but to change how the Projects are drawn.

Merge when two Projects share most of their materials, and you keep needing the same decisions in both. Two Projects with nearly identical instructions and overlapping documents are one Project with an artificial boundary, and the boundary is costing you effort.

Split when one Project has grown so large that answers have got worse. A Project with dozens of loosely related attachments gives the model more to search through and makes it less likely to pick the passage you meant. Splitting along a clear line, and carrying a core brief and decision log into each half, often improves both.

Neither choice is permanent. The test is simple: if you spend more time moving context between two Projects than working in them, the boundary is in the wrong place.

Testing What Crosses in Your Account

Because account-level capabilities vary, it is worth running a short test rather than relying on any description.

1. In Project A, start a chat and establish something distinctive that appears nowhere in either Project's instructions or documents. An invented codename or a made-up rule works well.
2. Confirm it took by asking a follow-up in the same chat.
3. Open Project B and start a new chat from inside that Project.
4. Ask a question whose correct answer depends on the distinctive detail, without naming it.

If Project B knows the detail, something at account level is carrying context across Projects, and you should find which setting is responsible so you understand what is being shared. If it does not, you have confirmed the default boundary. Repeat the test after product updates that mention memory. The same approach for checking conversation-level recall is in Does Claude Remember Previous Conversations?.

Mistakes That Make Sharing Worse

A few habits reliably make cross-Project context worse.

Copying entire conversations between Projects. Pasting a long transcript into another Project's chat uses a lot of room and buries the few lines that matter. Extract the decisions and current state; leave the transcript behind.

Letting copies drift. If the same document is attached to three Projects and you update it in one, the other two are now wrong and will be applied confidently. Keep one master copy outside Claude and replace attachments when it changes.

Duplicating reference material everywhere. Large reference documents belong in the Project that needs them. Attaching them to every Project adds noise that makes retrieval less precise.

Relying on an untested memory feature. If you assume something is carrying across and stop maintaining the brief and log, you will discover the assumption was wrong at the worst moment.

When the Context Needs to Leave Claude Too

All of the patterns above have one thing in common: the shared context lives in documents you control, and Claude is given a copy. That has a useful side effect. The same core brief, decision log and handover work just as well in ChatGPT or Gemini, so the effort you put into sharing context between Projects also makes your work portable between assistants. The practical side of working across two assistants is covered in Using ChatGPT and Claude Together.

MindLock is built around that idea. You save conversations worth keeping with Ctrl or Cmd plus S in Claude, ChatGPT, Gemini or Perplexity, or with the "Save to Memory" button from the Chrome extension, which is loaded unpacked in developer mode rather than installed from a store. Uploaded conversations are distilled into memory documents, a profile memory plus topic memories, that you can read and edit, and semantic search with Ctrl or Cmd plus K finds material across your conversations, memories and contexts. Generating a context block packages the relevant memories into text you paste as the first message in any Project or any assistant. The process is described in Generating Context.

To be clear about limits: MindLock does not connect to your Claude account or change how Projects behave, and nothing is captured automatically. Saving is something you do, and memory documents update when you re-run distillation. Local distillation needs a WebGPU-capable GPU; the cloud option and cloud sync are on the Pro tier, set out on the pricing page.

The Short Version

Claude Projects are separate containers. A chat in one Project cannot see another Project's instructions, documents or conversations, and you should assume nothing crosses unless a test in your own account shows otherwise.

Sharing context between Projects is therefore a matter of putting it in each one deliberately. Keep a short core brief for stable facts and put it at the top of each Project's instructions. Keep a decision log, attach it where it applies, and promote critical decisions into instructions. Use a handover message for current state. And if you spend more time moving context than working, redraw the Project boundaries.

Keep the master copy of all of it outside Claude. Then it survives product changes, stays consistent across Projects, and works in whichever assistant you open next.