Claude Code: Monorepo vs Multiple Repos
Teams adopting Claude Code often ask whether they should move to a monorepo so the AI can "see everything". This article compares how Claude Code behaves in each setup, and explains why changing your repository structure isn't the only way to get cross-repository context.
How Claude Code behaves in a monorepo
In a monorepo, all the code is under one folder, so Claude Code can technically reach all of it.
- What works well
- Claude can follow imports between packages without any setup. A change and its consumers can be updated in one task. A single CLAUDE.md can describe the whole system.
- What still goes wrong
- Being reachable isn't the same as being understood. In a large monorepo, Claude still has to search for which packages matter, which costs time and context. Calls between services over HTTP or queues aren't imports, so Claude can't follow them by reading imports alone.
How Claude Code behaves with multiple repositories
- What works well
- Each repository is small and focused, so Claude understands it quickly. Ownership and permissions are clear.
- What goes wrong
- Claude only sees the repository it was started in, unless you add more with --add-dir. Changes that ripple across services (API contracts, shared types, events) are where most mistakes happen. Repositories you haven't cloned are completely invisible.
Side-by-side
| Monorepo | Multiple repos | |
|---|---|---|
| Claude can reach all the code | Yes | Only what you add |
| Claude knows how services connect | Partly (imports only) | No |
| Context cost on large systems | High | Low per repo, but blind outside it |
| Cross-service changes | Easier | Hardest |
| Migration effort | Large | None |
Should you migrate to a monorepo for Claude Code?
Usually not. A monorepo migration is a big engineering decision with consequences for CI, ownership, access control and release processes. It shouldn't be driven by one tool. And even a monorepo doesn't give Claude a map of runtime relationships between services.
What Claude actually needs is two things, reach and relationships, and both can be provided without moving code.
Getting monorepo-style context while keeping separate repos
CodeZero indexes your organisation's repositories and works alongside Claude Code inside VS Code:
- Reach: Claude can read from any indexed repository, even ones you haven't cloned.
- Relationships: the Code Graph shows how modules, files, data and repositories connect, and marks service calls that are inferred separately from those resolved directly from source.
- Separation where it helps: each repository keeps its own chat and workstream, while organisation-wide context stays available in every conversation.
You keep your repository structure, and Claude gets the cross-repository view.
FAQ
Is a monorepo better for AI coding agents?
It makes code easier to reach, not easier to understand. Indexing and dependency mapping matter more than repository layout.
Can I use CodeZero with a monorepo?
Yes. The Code Graph and Feature Mapping are useful in a large single repository too.