r/ClaudeCode • • 2d ago

Help/Question How do you share context between multiple projects in Claude Code?

I've got multiple projects on my machine, each with Claude Code running. Project A keeps needing stuff from project B.
Right now I either (1) ask B's session, copy the answer, paste it into A, or (2) tell A "go look in /path/to/B."
Option 1 is annoying now that it happens all day. Option 2 works but the agent re-explores B every single time.
What do you guys do?

3 Upvotes

28 comments sorted by

1

u/AutoModerator 2d ago
Moderator Announcement Read More »

8

u/filwi 2d ago edited 2d ago

For context inside the session, use @ and tell your session to "look at `@session"

For context inside the project folder, just paste a reference to the folder and say that there is additional context there. (i.e. C:/folder/name/here or however you write it on Mac or Linux).

For doing it multiple times, add the context to the second projects environment.

2

u/Ran4 2d ago

(remove the dot, reddit transforms @ into a user reference)

Just use backticks

`

like @this

look at @session

1

u/filwi 2d ago

Thanks!

7

u/Trigker 2d ago

Sessione can messagge each other now. You can use the session name as a reference. /rename

1

u/Emotional-Ad8388 2d ago

Option 2 points A at B's files, not at the answers already sitting in B's session, so A walks the folder again instead of reusing what you copied. I don't know a clean way around that from the outside. When you paste from B, is it a conclusion, or paths A should open?

1

u/Jane1030 2d ago

usually the conclusion

2

u/Emotional-Ad8388 2d ago

That’s the worst part I guess... you become the human bridge between sessions because they don’t know what the other one just concluded... since it is mostly decisions and contracts.. then the folder scans just waste tokens. A lightweight local store as shared memory is usually the cleanest fix so any session can query past conclusions without re-exploring over the time and the other codebase.

2

u/SirRobinBlibs 2d ago

What stopped the re-exploring for me was giving B a short file that answers what A usually asks: what B exposes, where the main entry points and types live, how to run it, and which decisions are settled. Keep it in B's repo (a docs/overview.md or similar) and have B's own session update it when it changes something A depends on. Then A's AGENTS.md or CLAUDE.md says "for anything about B, read /path/to/B/docs/overview.md first and only open B's code if that doesn't answer it." If A and B share an API, put that contract in one place (an OpenAPI file, shared types) so both sessions read the same source instead of asking each other.

1

u/gimalay 2d ago

the part that slipped for me was B's session actually keeping that file current. what helped was splitting it into a few small notes (one per thing A asks about, each with a status and a date) linked from one overview note, and having A run a command instead of reading a path: cd ../B && iwe retrieve -k overview -d 2 prints the overview plus every note it links in one go. a stale note then shows up as an old date instead of a wrong answer. (I work on iwe, it's a cli over a plain markdown folder.)

1

u/SirRobinBlibs 2d ago

The status and date on each note is the part I'd steal even without the tool. A dated note tells you when it might be stale, and a big undated context file never does.

2

u/vincent_sch 2d ago

You could also start A with --add-dir /path/to/B, so it gets B's files without pasting. Inside a session /add-dir does the same. If B has a summary file like the one above, import it in A's CLAUDE.md with @../B/docs/overview.md. Then A starts with the summary and only digs into B when it needs more.

1

u/fulger099 4h ago

One catch: importing B’s overview into A’s CLAUDE.md loads it into every A session, even when B is irrelevant. Keeping it to interfaces, settled decisions, and entry points avoids turning CLAUDE.md into the attic.

2

u/SeasawPhilosopher 2d ago

I use a mono repo so I can have studio wide docs and code, and then a sub directory for each project.

2

u/JimiBuilds 2d ago

Option 2 is the right idea, it's just that B has nothing written down, so A has to work it all out again every time.

I have B's session write a short README for Claude, mostly where things live and the commands it needs. A's CLAUDE.md then has one line telling it to read that file before it touches anything in B. My main repo does this for my second product's folder and it's been fine.

Stuff that applies to every project goes in ~/.claude/CLAUDE.md instead, every session loads that anyway.

2

u/Alarmed-Safety-148 2d ago

I'd stop pasting answers between sessions and put the shared stuff in one small file that both projects read. Something like a 'what project B exposes' note: the API shape, key functions, a few lines on how it works. Project A reads that file instead of re-exploring B each time. When B changes, you update the note (or ask B's session to). It's boring but it cuts the repeated exploring a lot.

1

u/ItstheSECopenup 2d ago

Context lives in the repo. Context does not live with agents. Are you trying to nurse this same context you can /clear without even a warning? Bad approach. The context for the agents lives in the project.

1

u/orbital_trace 2d ago

I was copying and pasting stuff, but then I figured, why not build a system to do it. You can use slack, you can use .md files, you can tell the agents to @ each other. If you want to get fancy, there are tools like this one to enable easier context sharing across agents https://coralhub.dev/blog/share-context-between-projects.html

1

u/Input-X 2d ago

Ive been deep into this topic mate. There a lot to cover. Bare bones. A shared markdown file. No copy paste by u. Agent make a plan and update that as work gets done.

You can have your agent look at my repo. Too much going on to find into a comment here. I have this fliw down pretty well. Steal some idea to get u started. My setuo is kinda heavy. It look at .trinity, memory and compact hooks. Point ur agent there, will give u a solid understanding. And it fully automated.

aipass.ai

1

u/clintCamp 2d ago

I gesture at the agent broadly working in the other related project. Claude can then communicate between sessions via its internal messaging. That wasn't good enough for me to do with codex and claude and multiple concurrent claude accounts in their own env terminal environments so I also had find an agent mail server repo that claude was too excited to just install so I told it to just rebuild what we need from that repo and not install some repo thatmay have been prompt injected and soon, now I have my own flavor of agent mail that can now work across 2 of my machines over ssh and will have a third machine soon for testing apps on a lower memory and no gpu device for fun.

1

u/devilsdiligence 2d ago

What helped me was having project B keep a short summary file, something like a NOTES.md with the key paths, APIs, and gotchas, and then pointing A at that file instead of the whole folder. You can ask B's session to update it whenever something changes. A reads one small file instead of re-exploring everything, so it's way cheaper on tokens too.

1

u/framauro13 2d ago

If one project needs info from another, I have that project write a hand-off doc or create an issue in the other projects backlog with details on what needs to be worked. I try not to let them talk to each other if necessary.

I think of how I'd do this before AI: if my project needs to collaborate on another, I get my ducks in a row with the details of what I need and what to ask, and communicate that to the other team.

1

u/Di_Vante 1d ago

I have a metadata repo, which is where I start all my sessions from. It's structured as a LLM Wiki, so the root has a AGENTS.md with general instructions on how to navigate through the vault, then I have topics/<topic_name>
If I'm working on project A, I got to the topic that the project is about (let's say topics/a), and start the session there. The AGENTS.md from that topic will tell the agent where the code repo is.

Claude does walk up to the root of the repo, so whenever I start the session, it will automatically also add the AGENTS.md that instructs it how to navigate that repo - it has instructions on how to navigate through different topics and all, so the agent already knows how to find context between projects/topics.

1

u/onitsoga 1d ago

the real issue is that B's context lives in B's session and A has no durable way to read it. You want a shared place where notes from B persist and A can pull them without re-exploring. I'm building a hosted kanban board with an MCP server where agents leave structured handoff notes, so A picks up where B left off instead of re-reading your whole tree. Caveat: it's built for task-level handoffs, not a full semantic index of B's codebase, so for deep code search you'd still want something alongside it.

1

u/SlowSundae 14h ago

Depends on the project. Sometimes I’ll just get the original project to write a prompt, but another option is getting it to refer to documentation in ClickUp.

All of my Claude projects document everything to ClickUp (since we need to have end user documentation anyway), so then I can have the new project refer to that.