[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:

1. A shared API contracts repo (schema change)
2. A backend service repo (implementation)
3. A frontend repo (form validation)
4. 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:

1. Start with one or more repos based on the task description
2. Discover additional repos as it works (via dependency analysis, import tracing, or configuration references)
3. Clone and work on additional repos as needed
4. 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:

1. Check out the relevant branch in each local repo (or prompt to clone missing repos)
2. Restore the full conversation context
3. Set up /add-dir across 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:

1. Receives a task + set of candidate repos
2. Spins up a pod with all repos cloned
3. Runs Claude Code via API with multi-directory access
4. Coordinates branches across repos
5. Applies per-repo push/PR policies
6. 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

1. I'm working across multiple repos — a shared API contracts library, a Node.js backend service, a React frontend, and a Kubernetes infrastructure repo
2. 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
3. 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
4. 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