Support for go mod operations against private repositories

[dwalker-va]

Describe your question
Currently the way that the copilot agent environment is configured prevents the agent from being able to read other private repositories or have tokens configured, but this limits its effectiveness in being able to execute routine tasks like updating private dependencies.

For example, if your company builds its APIs on top of protocol buffers, you might have a protocol buffer repository (like https://github.com/googleapis) which builds into langauge-specific package management systems, or a git repository in the case of golang (like https://github.com/googleapis/go-genproto), potentially a repository for bundling that generated code into an SDK (like https://github.com/googleapis/google-cloud-go), and then finally a target repo that actually needs to update that SDK where the agent is working in. Tasks that would be achievable for Copilot with a monorepo/simplistic API authoring setup become impossible with its current lack of configuration options.

Other tools like https://github.com/langchain-ai/open-swe take a different approach to authentication that enables the agent to have wider access to an organization's repositories (although it is not perfect either). On some level, I appreciate the default security stance of locking the agent's authentication scope to the repository its working in, but the lack of customization here severely limits its effectiveness in organizations that have a wide repository layout and many internal dependencies.

Are we thinking about offering more configuration over Copilot's authentication credentials? What I would be looking for would be a way to give the agent read access to other repositories within my organization and limit write access to the repo its working in.

[nhu-do]

👋🏼 Hey there! One suggestion would be to provide the GitHub MCP server with a more permissive token to read other repositories within the organization.

[dwalker-va]

Thanks for the response.

This issue may be scoped mostly to tools like go get that end up invoking git under the hood in Copilot's environment and not through the Github MCP directly. It's the underlying git tool in Copilot's environment that would need that personal access token rather than the MCP. I am guessing that is what is going on here, let me know if this makes sense; providing some session log excerpts of what I mean here:

For clarity, this run was done after following the linked instructions to create a COPILOT_MCP_GITHUB_PERSONAL_ACCESS_TOKEN in the copilot environment.

And then later on, it does end up using the MCP to figure out what release tags are available, figuring out what version it does need to pull using go get, but of course it's never able to actually execute that command: