[FEATURE] Multi-repository support for remote/web sessions
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Problem Statement
Claude Code remote/web sessions assume one session = one repo = one branch = one PR. This makes remote sessions unusable for multi-repo architectures, which is how most organizations structure their code the moment they have multiple teams deploying independent services.
More importantly: by building all remote tooling around single-repo workflows, Anthropic is creating ecosystem pressure toward monorepos. This isn't a neutral tooling choice — it actively disadvantages the organizations that are most likely to be Claude's paying customers.
The monorepo assumption is wrong for most organizations
The "just use a monorepo" response is common, so let me address it directly.
Monorepos work in two specific situations: early startups where there's effectively one team and everything lives together naturally, and the handful of tech giants (Google, Meta) that have invested years and tens of millions into custom build tooling (Bazel, Buck, custom VCS). Every organization in between — which is the vast majority of the software industry — gets the costs without the tooling to manage them.
Concrete costs of monorepos for mid-size organizations:
Ownership erosion. When 15 teams share a monorepo, ownership boundaries blur. A team owns a directory, but anyone can submit a PR that touches it. Code review policies become either too permissive (rubber-stamping cross-team changes) or too rigid (bottleneck on a CODEOWNERS team that's already overloaded). In separate repos, ownership is structural and enforced by access control. In a monorepo, it's a convention that requires constant vigilance.
CI/CD complexity becomes a platform team's full-time job. A monorepo with 15 services needs build tooling that can determine which services are affected by a change, run only the relevant pipelines, and handle the dependency graph. This is non-trivial. Most organizations don't have the tooling budget to build or maintain this. They end up either running all pipelines on every change (slow, expensive) or building fragile path-based triggering rules that break constantly. With separate repos, each repo has its own pipeline. Simple, independent, owned by the team that owns the service.
Deployment coupling. Monorepos tempt teams into coupling deployments. "While I'm deploying my change, let me include this other team's change too — it's in the same build." This erodes independent deployability, which is one of the key benefits of microservices in the first place. Separate repos make independent deployment the default.
Access control granularity. In consulting and regulated industries, different repos may have different access requirements. A contractor might have access to the frontend but not the billing service. A junior developer might have access to the test infrastructure but not production config. Monorepos make fine-grained access control either impossible or dependent on fragile path-based rules. This is a real compliance concern in healthcare, finance, and government work.
Scaling pain. A monorepo with 5 years of history from 15 teams becomes a multi-gigabyte clone. Shallow clones help but break tooling that needs history. Sparse checkouts add complexity. Git performance degrades. These are solved problems at Google-scale, but Google wrote its own version control system to solve them.
These aren't theoretical concerns. I've worked as both a developer and platform engineer across large Nordic enterprises over 26 years, and the pattern is consistent: companies that adopt monorepos without Google-scale tooling investment spend 1-2 full platform engineering headcount just maintaining the build system. That's a real cost that multi-repo architectures avoid entirely.
What breaks in practice with single-repo remote sessions
A typical cross-cutting task: "Update the user profile validation rules."
This might touch:
- A shared API contracts repo (schema change)
- A backend service repo (implementation)
- A frontend repo (form validation)
- An infrastructure repo (API gateway routing if a new endpoint is added)
I don't always know which repos are affected when I start the task. A human developer discovers this as they work — "oh, this schema change means I also need to update the consumer in the frontend repo." An AI agent should work the same way.
Today, I would need to:
- Start four separate remote sessions, each without context from the others
- Manually coordinate branch names across repos
- Figure out the correct merge order myself
- Track which branches across which repos form a coherent change set
Or: I stay local, use /add-dir, and lose the async benefits of remote sessions entirely.
Proposed Solution
Proposed solution
Dynamic repo discovery, not a static repo list
Rather than requiring the user to enumerate repos upfront, the agent should be able to:
- Start with one or more repos based on the task description
- Discover additional repos as it works (via dependency analysis, import tracing, or configuration references)
- Clone and work on additional repos as needed
- Apply changes across all repos it touched
This mirrors how human developers actually work and would require access to the user's GitHub organization (or a configured set of repos the agent is allowed to discover).
A simpler first step: allow the user to scope the session to a GitHub organization or a list of repos the agent is allowed to access, and let the agent decide which ones are relevant.
# Scoped to an org — agent discovers relevant repos as it works
& --scope org/my-org "Update the UserProfile validation to require email verification"
# Or explicit list of candidate repos
& --repos org/api-contracts,org/backend,org/frontend,org/infra \
"Update the UserProfile validation to require email verification"Coordinated change sets, not independent PRs
When a multi-repo session completes, the output should be a change set: a group of branches across repos that together form a coherent change. The UI should present these as a unit, not as four unrelated PRs.
Optionally, the agent should be able to create a tracking issue or link the PRs to each other, indicating merge order and dependencies.
Commit and push control
Remote sessions currently auto-push and can create PRs. For professional contexts — consulting, contractor work, client repos — this needs to be configurable:
- Push policy: always / ask / never (teleport-only)
- PR policy: auto-create / draft / never
- Per-repo overrides: auto-PR on my own projects, never-push on client repos
This is valuable even for single-repo remote sessions, but becomes critical with multi-repo where different repos may have different access and trust levels.
Teleportation for multi-repo sessions
When teleporting a multi-repo session back to a local machine, the CLI should:
- Check out the relevant branch in each local repo (or prompt to clone missing repos)
- Restore the full conversation context
- Set up
/add-diracross all repos so the user can continue locally
The ecosystem argument
This isn't just a feature request for my workflow. It's about what kind of development practices Claude Code encourages across the industry.
AI coding tools are becoming the default development environment. The architectural assumptions baked into these tools shape how new projects are structured and how existing projects evolve. When the tooling only works well with monorepos, organizations face pressure to adopt monorepos regardless of whether that's the right choice for them.
Anthropic is well-positioned to get this right. The local Claude Code experience with /add-dir already demonstrates multi-repo awareness. The GitHub proxy architecture already handles authentication per-repo. Extending remote sessions to support multiple repos is architecturally feasible — it's a prioritization choice, not a technical limitation.
The alternative is that every multi-repo team either abandons remote sessions or builds custom workarounds, while the tooling ecosystem continues to calcify around monorepo assumptions.
How I would build this myself (and why Anthropic should do it instead)
I have the infrastructure: a Kubernetes cluster, an existing task tracker that maps Claude Code sessions to tasks across projects with per-project configuration, and 26 years of experience as both a developer and platform/DevSecOps engineer. I could build an orchestrator that:
- Receives a task + set of candidate repos
- Spins up a pod with all repos cloned
- Runs Claude Code via API with multi-directory access
- Coordinates branches across repos
- Applies per-repo push/PR policies
- Reports session metadata back to a task tracker
The problem: if I build this, it works for me. If Anthropic builds it, it works for everyone using Claude Code. And if I build it and then Anthropic ships a native version six months later, my effort is wasted. This dynamic discourages the community from solving real problems and instead concentrates power in Anthropic's hands to set architectural defaults for the industry.
The better path: Anthropic ships multi-repo support as a first-class feature, informed by feedback from practitioners who work in multi-repo environments daily.
Alternative Solutions
Current workarounds:
- Running separate remote sessions per repo, then manually coordinating branch names, merge order, and tracking which branches form a coherent change across repos
- Staying local using /add-dir to work across multiple repos in one session, but this means I can't close my laptop and come back to finished work
- Using VNC from my iPad to my MacBook to get pseudo-remote execution, but the machine still needs to stay awake
- Building a custom task tracker (git-synced JSON files mapping sessions to tasks across projects) to keep track of what belongs together, since the tooling doesn't do this natively
Other tools:
- The open-source multi-claude project attempts multi-repo workflows but is focused on parallel single-repo sessions, not cross-repo context sharing
- Claude Code's own /add-dir already solves this locally — the gap is that remote sessions don't support the equivalent
Priority
High - Significant impact on productivity
Feature Category
Other
Use Case Example
- I'm working across multiple repos — a shared API contracts library, a Node.js backend service, a React frontend, and a Kubernetes infrastructure repo
- A task like "add email verification to user profiles" requires changes across several of these repos, and I often don't know which ones are affected until I start working and follow the dependency chain
- With this feature, I could start a remote session scoped to my GitHub org, let the agent discover and clone the repos it needs as it works, and get back coordinated branches across all affected repos as a single change set
- This would save me time because today I either run separate remote sessions per repo with no shared context and manually coordinate branches, or I stay local with /add-dir and lose the async benefits of remote sessions entirely
Additional Context
/add-dir proves multi-directory support works locally
claude-code-action#497 shows demand (24+ upvotes)
The GitHub proxy security model already handles per-repo authentication
Session teleportation would need extension for multi-repo checkouts
15 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of any of the three listed issues.
#20559 is about inter-session communication. My request is about a single remote session working across multiple repositories.
#23505 is about repo relationship awareness/topology. Related but different — I'm requesting that remote/web sessions can clone, modify, and produce coordinated change sets across multiple repos, not just understand their relationships.
#16089 is about git worktree context within a single repo. My request is specifically about multi-repo support in remote sessions, including dynamic repo discovery, coordinated branching, and per-repo push/PR policies.
None of these address the core problem: remote sessions are locked to a single repository, making them unusable for multi-repo architectures.
I'm not sure if this has changed recently, but I was just able to kick off a claude code web session with multiple repositories attached to it.
But how will it manage if you have different hooks specific to each repositories?
I can't believe this hasn't been implemented, yet. This is basic table-stakes for broad adoption. And thanks to the OP for the well documented Issue. Come on, Anthropic! Get this one moving!
I'd like to add two use cases that highlight the need for this feature beyond just having multiple repos open — specifically around carrying conversation context and using each project's own tooling (CLAUDE.md, skills, hooks, Makefile/Docker).
Use case 1: Microservices — Verify a change through another service's tooling
I'm refactoring how entities are initialized in a web application (project A). This change affects how certain database records are created. To verify the change, I need to run a specific database query through a separate microservice (project B) that owns the database tooling and has its own Docker/Make setup.
Today, I have to open a separate Claude Code session in project B and manually re-explain the full context of what changed in project A and why. The second session has no awareness of the refactor, the affected entities, or what I need to validate.
Use case 2: Related but independent projects — Coordinated changes across repos
A team maintains a backend API (project A) and a separate client SDK or frontend app (project B). A breaking change in the API response schema requires updating the SDK's type definitions and tests. Both repos have their own CI, linting rules, CLAUDE.md conventions, and custom skills.
Currently, Claude can only fully assist in one project at a time. Working on project B means losing all the configured tooling and project-specific knowledge from project A, and vice versa.
What would make this work
The key piece isn't just reading/editing files across repos (which is partially possible today via absolute paths). It's that each project's full configuration (CLAUDE.md, skills, hooks, execution environment) should be available when acting on that project, while the conversation context from the originating project carries over. Without this, cross-project work requires duplicating context manually between sessions.
Extremely well written request that more eloquently articulates the issues at core in my duplicate request. Please implement, Claude folks.
the multi-repo coordination problem is real, but i'm not sure it's CC's problem to solve.
CC's job is to do one repo well — understand the codebase, make good edits, run checks, open a PR. asking it to also coordinate branches across repos, manage merge order, and track cross-repo change sets is a different layer of the stack.
a thin orchestration layer above CC handles this better than native multi-repo support would. you register your projects, define a pipeline, route tasks to the right repo at the right time. each CC session stays focused — one repo, one task, one PR. i run 10 long-running CC instances managing 5 parallel workers across 15+ repos and it works smoothly — because each session only has to think about one thing at a time.
the risk of native multi-repo support is that it makes CC do too much. one session holding context for 4 repos is a session that's worse at all 4 repos than 4 focused sessions would be.
Yeah I hear you and had this same thought, the issue is that I still get a massive speedup having Claude with immediately access to 5 repos that it can quickly go and do changes against vs one session per service.
I've also tried using
/add-dirbut this just adds the directory immediately and doesn't create a worktree for it or have it on the same branch.I could see Claude slowly moving towards the IDE setup we already see, you either open one project or multiple and then can work with them. The downside is that I think this touches on the point you're making, it then gets tricky knowing which project gets a certain memory and having your session make 'clever' decisions based on what it's "learnt" across the multiple projects.
I think it will come though, or a way to better co-ordinate between multiple services at once.
@Skowt imagine if you split into 2 stages(not 2 stage in a single cc session), in planning stage there will be multiple subagent collect info from each related repo, and the orchestrator cc build a multi-level task tree, then in executing stage you just parallel spawn cc for each subtree(for each proj), they have separate worktree and prs, and pr review will also be parallel and focus on the impl in a single repo
and the researcher or coding subagents may even not cc, but a lighter runtime using opensource highspeed model; cc only doing distribution and collection/evaluation -- that's what i'm working on
Yeah so you'd do
/add-dirfor each dir then go through the plan and then setup your skills/subagents in a way to make sure they always create worktrees and separate branches when they get used. Yeah fair, could be a potential workflow if you can get it happening consistently.although it's not well-documented, cursor handles this in a simple and effective way: its environment.json file (schema here) allows for a simple list of repository names which the cloud agent's token has read-only access to. This helpfully keeps the specification of which repos are needed aligned with the code that needs them, right in the repo.
My company has a large number of private repos for microservices, shared infrastructure, and reusable modules in various languages, and this capability is invaluable. I'd love to see it in claude.
I'm really curious how important it is for Claude to be started in a specific directory, particularly for memory.
I see that it attempts to store information about a particular project in its ~/.claude/projects/ directory which seems to be based on where you start claude but I don't know how this then works with other directories included with
/add-dir? Do they just not get any memory? And what happens if you start claude in a gittree which is in another directory but about a long-running project?Claude's definitely been built for a single repo/folder focus and all the functionality has been made with that concept in mind. It definitely seems like to get the full potential of auto memory (and CLAUDE.md file reading) you have to spawn one claude instance per repo or you have to ensure that it uses subagents when interacting with those folders.
There must be a better way 👀 Or we just ignore auto memory for now.
@birdmanmandbir @Skowt the 2-stage pattern you're describing (planning subagents → orchestrator → parallel execution) is exactly the gap we ended up filling outside of CC itself.
We built mcp-coordinator as the coordination layer for that pattern: an MCP server with an embedded MQTT broker, so any number of CC (or Cursor / Cline / Aider) sessions can announce intent before editing, and a consultation thread opens automatically when impact crosses a threshold. The orchestrator becomes optional — peer-to-peer coordination works for the simpler cases.
Agreed with you both that this probably shouldn't be CC's problem to solve — MCP is the right boundary for it. Sharing in case useful for what you're building.
Adding a concrete root-cause detail from debugging this on a web session, in case it's useful for whoever picks this up.
The single-repo limit isn't just a missing UI affordance — it's actively enforced by the git wiring in a way that silently overrides credentials the session already has. In the sandbox, git is configured with:
So every
https://github.com/…URL is rewritten to route through a per-session git proxy that injects its own scoped token and only authorizes the one attached repo. The practical consequence: even when the user has a perfectly valid PAT in the environment — one with full access to the other repos, used successfully from every other machine — a plaingit cloneof a sibling repo from the setup script never gets to use it. TheinsteadOfrewrite happens before authentication, the proxy substitutes its own narrowly-scoped credential, and the user's working token is silently ignored.That's the part worth fixing alongside first-class multi-repo config: honor the credentials the session already legitimately holds. If the connected account / PAT can already see a repo, cloning it shouldn't be blocked by infrastructure the user can't see or configure. A supported "additional repositories" setting that adds repos to the proxy allowlist would solve the common case, but the underlying principle is that a valid, user-provided token shouldn't be silently overridden by a session-scoped one.