🫤 Guidance on how to use Copilot Coding Agents with Poly Repo structure ❓

[michael-proctor]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Copilot Coding Agent

Body

Have been trialling Github Coding Agents in our organization. One of the challenges we are facing is the poly repo structure. Each library, service is it's own repository. When doing a feature which requires changes across boundaries it becomes painful to link up the work from each agent.

Although I understand the core principle of the sandboxed environment only having access to the targeted repository, is there anyway we can provide rules to give it access to other repositories so it can have complete context?

We have a legacy codebase which is a distributed monolith in a mono repo pattern, Copilot does great at seeing the context across the boundaries and makes the required changes across the multiple projects.

Is there any guidance on how to operate in a poly repo pattern with Coding Agent?

[michael-proctor]

I haven't tried but did consider trying to do a checkout of the other repositories in the copilot-setup-steps, but this is messy and also comes with challenges of it correctly creating new branches on the "associated" repos along with creation of PRs etc. (I'm not sure if it can even do a git clone), although found you can instruct the agent to change git config :D

Is there anything in the roadmap to address this by chance?

[WilliamRossCrane]

Currently, Copilot Coding Agents are sandboxed to a single repository, so they don’t natively handle cross-repo changes in a polyrepo setup.

Some workarounds include:

• Cloning other repos locally so the agent can read them, though managing branches and PRs across multiple repos can get tricky.
• Providing relevant snippets from other repos in the agent’s prompt, which works for small dependencies but doesn’t scale.
• Custom scripts to automate cross-repo PRs while letting the agent operate within each repo individually.

At the moment, full polyrepo support isn’t officially available, so the best practice is to treat the agent as repo-specific and coordinate multi-repo changes manually or with tooling.

Mark as answered if your happy with this :D

[Citrate-0358]

Gemini said
Use a multi-root workspace in VS Code to give the agent simultaneous local context across all your repositories for cross-repo edits.

Maintain a shared schema or .github/copilot-instructions.md in each repo to explicitly define the contracts and paths of its dependencies.

[hsinhan-h]

Hi @michael-proctor , this is a very common pain point and it also bothered me quite a bit when I first started using Copilot in a poly repo setup too. Here are my key takeaways after working throughcross-repo devlopment in my organization:

1. Use VS Code as your IDE :
   Go to File -> Add Folder to Workspace to add all the relevant repositories into a single workspace.

2. Pin the files you needed as context:
   Navigate to the files across repos that are relevant to your feature, then right-click: and select "Add File to chat"
3. Let Copilot agent mode do the heavy lifting!
   Agent Mode can explore across all of them and make coordinated edits spanning multiple repositories simultaneously.

This gives Copilot a unified view across your repositories without needing to change your actual repo structure. Hope this helps!

[michael-proctor]

Appreciate the reply, I am aware locally you can do this, however, this is actually about using the cloud agents, we are trialling the Jira copilot integration.

In this case the issue is assigned to Copilot which a job running spins up an environment and copilot operates in there. The issue is this environment is sandboxed to a single repo.

Was hoping someone in GitHub might give some insight as a poly repo pattern is a very common pattern, and also in normal agile practice it is normal to vertical slice which would mean needing access to multiple repositories for context.

Otherwise you need to get very granular with horizontal slicing to cover each piece of work separately without copilot being able to get a clear end to end view of the work.

We have used it in a mono repo codebase and it worked well, but poly repo is challenging.

[ofekron]

I would keep the cloud agent repo-scoped rather than widening one agent’s credentials across the organization. For a vertical feature spanning polyrepos, coordinate several bounded repo-specific tasks around one shared contract.

A workable sequence is:

1. Create a feature-level plan that names every affected repository, dependency edge, compatibility constraint, and end-to-end acceptance test.
2. Make the API/schema/event contract the shared artifact. Version it first so each repo agent works against the same source of truth.
3. Assign one isolated agent/session per repository with only that repo’s credentials and explicit inputs/outputs.
4. Order dependent work: contract/provider change, consumer changes, then cross-repo integration verification. Do not let independent agents guess unpublished interfaces.
5. Link all draft PRs to one tracking issue and record the exact dependency/merge order.
6. Use a single integration owner to verify the combined result in a composed test environment before any final merge.
7. If compatibility cannot be atomic, use an explicit expand/migrate/contract rollout rather than relying on simultaneous agent execution.

This does not give Copilot’s cloud agent cross-repo context, but it turns the sandbox boundary into a useful ownership boundary and avoids distributing broad tokens to one autonomous process.

Maintainer disclosure: I am building Better Agent, a local web workspace that can supervise separate Claude, Codex, Gemini, and other coding-agent sessions with persistent plans, files, approvals, and recovery: https://github.com/ofekron/better-agent

It is source-available and free for non-commercial use. It can help coordinate those repo-scoped sessions, but it does not change Copilot Coding Agent’s cloud sandbox or grant it cross-repository access.