GitHub code integration

There is a difference between an agent that can talk about code and one that can reach yours. The GitHub code integration turns the first into the second: it binds a GitHub repository, the tools to read its issues and pull requests, and the GitHub Copilot runtime into a single connection, so when you ask the agent about a pull request or a failing check or a piece of the codebase, it answers from your actual repository rather than from a general sense of how code usually works.

This page is the how-to for that connection: what it ties together, how you set it up, which credential lets the Copilot runtime run, and where it sits next to the other ways GitHub shows up in Disco Parrot. For the wider picture of how Disco Parrot connects to your stack, read integrations and providers.

What the integration binds together

A GitHub code integration is not a fourth credential to mint. It is a connection that ties three things you may already have into one, so they work as a unit:

• The repository, through a GitHub repository provider. This is the credential side: the access that lets the platform reach the repository on your behalf.
• The tools to read it, through a GitHub MCP connection. This is what gives the agent calls it can make against GitHub: search the code, read a file, list pull requests and open one for its diff, reviews, and checks, see the GitHub Actions runs, and open an issue. The next section walks the surface; the short version is that they are calls against the live repository, governed one at a time.
• The runtime to reason with, the GitHub Copilot model, wired in as the integration's default. Copilot is one runtime among several, and code-aware chat runs on it unless you point the connection at a different one.

Binding them is the point. A repository provider on its own gets an agent a clone to work in; the MCP tools on their own give it calls it can make; the Copilot runtime on its own is a model. The integration is what makes the three act as one connection, so a single setup gives you chat that can reach the repository, read what is happening around it on GitHub, and reason about both.

You configure it from Integrations under Platform, the same place the Azure DevOps integration lives. The integration carries the repository provider it is built on, the GitHub MCP connection it provisions, and the Copilot runtime it defaults to.

What the GitHub tools reach

The integration provisions GitHub's own hosted tool server, so the calls the agent can make are GitHub's, not an approximation of them. They cover the surfaces a conversation about code actually touches, each one a call the agent makes when the conversation calls for it:

• Search the code. Find a symbol, a string, or a pattern across the repository, so "where is this function called" returns the real call sites in your source.
• Read a file. Open a file at a specific ref and read it, so the agent reasons from the actual lines rather than a remembered version.
• Read pull requests. List the open pull requests, then open one for its diff, its reviews, and the checks attached to it. The agent can tell you what a pull request changes and where it stands, not just that it exists.
• See the workflow runs. List the GitHub Actions runs, so "why is CI red" reads the actual run instead of guessing at the usual suspects.
• Open an issue. File a new issue when a conversation turns up something worth tracking, so the agent can hand work back to GitHub where your team picks it up.

The line that matters for trust: these calls read your repository and can open an issue, and that is the extent of what they change on GitHub. Each call is visible in the turn, governed on its own through approved actions, and bounded by your credential. The agent is not subscribing to your repository or holding a copy of it; it is asking GitHub a question, one at a time, and reasoning from the answer.

The credential, and the one rule that matters

GitHub access in Disco Parrot resolves through the repository provider, and there are three usable ways to authenticate it: a personal access token (classic or fine-grained), a GitHub App installation for a single central credential, and App OAuth, where the App defines what is reachable and your own identity carries the writes. App OAuth is the one most teams above a few engineers settle on, for the same reason it is the default on the provider page: central control of reach, your name on your own commits.

For code-aware chat there is one rule worth knowing before you wire it, because it is the thing that quietly decides whether Copilot turns on:

The credential is resolved per person, the same way it is for the repository provider, so each member of the team brings their own GitHub access and the integration makes its calls as them. What an agent can reach through code-aware chat is bounded by that credential, which is bounded by what the App or token can already see on GitHub. The agent is never handed more reach than the person behind it has.

Copilot is the default, not the only runtime

Copilot is the runtime the integration defaults to because it is tuned for code, but it is one runtime among several, and the model doing the reasoning is set by your runtime configuration, not hard-wired to this connection. The same cascade that picks a runtime everywhere else, skill, person, profile, then workspace default, picks the one code-aware chat reasons with.

That is also the answer for a team on a classic token. A classic ghp_ token cannot drive Copilot, but it still clones and still drives the GitHub tools, so the awareness is intact: the agent reaches your code, your pull requests, and your CI runs all the same. The repository awareness comes from the tools and the provider; the runtime is the model on top. A classic-token team gets the reach, the tool calls, and a grounded answer; what the Copilot path specifically asks for is a fine-grained token or App OAuth.

Only one GitHub code integration is configured per workspace. When you work across more than one GitHub repository, that is the repository provider layer's job: the integration builds on a provider, and the provider is where the repositories live.

What code-aware chat gets you

With the integration in place, chat can reach your repository and the work happening around it on GitHub, in the same turn it is reasoning about your plan. That second half is the part a code tool alone misses: the agent already has the plan you are shaping in front of it, so when it reads the pull request it can tell you not just that a check failed but whether the failure touches the work you are tracking.

You ask why a pull request is failing, and the agent reads the run and the diff rather than guessing. You ask what is left before a change can ship, and it reads the open pull requests and where each one stands. You ask how a function is used across the service, and it searches the actual code. The answer is grounded in your repository as it is right now, not in a snapshot or a summary.

That currency is the part a pasted code block or a week-old export cannot match: the run the agent reads is the one that just finished, the diff is the one on the branch as it stands, so the answer does not quietly go stale between when you copied the code in and when you asked about it.

That reach is a call at a time, which is exactly the line between this and the Azure DevOps work-item integration. Code-aware chat does not mirror your GitHub issues into Disco Parrot records or keep two systems in lockstep; it gives the agent the tools to read and act on GitHub when a conversation calls for it, through the same MCP and approved-actions machinery that governs every tool the agent can use. GitHub stays the system of record for issues and pull requests; the integration just lets the agent see it.

Which repository the chat is aware of follows the repository provider the integration is built on. The provider names the repository the platform can reach, and the code integration makes chat aware of that one, so awareness tracks the connection rather than every repository on your GitHub account.

Where it sits next to the repository provider

It is worth being precise about the overlap, because the repository provider and the code integration share a credential and it is easy to assume one is the other. The provider is the floor: it is what a sandbox uses to clone your code so an agent can work in it and open a pull request back. You can have that and nothing else, and an agent can do real work. The code integration is the layer that adds awareness: the GitHub tools and the Copilot runtime, so chat can reason about the repository and the activity around it, not just edit files in a clone.

Reading the repository is not changing your code

It is worth being exact about what code-aware chat does and does not touch. The chat reads: it reaches the repository's code, pull requests, and workflow runs to answer a question, and it can open an issue on GitHub when a conversation turns one up. What it does not do is edit your source. Changing code and opening a pull request back is the sandbox path, where an agent clones the repository, works in a disposable copy, and proposes the change for review. Code-aware chat is how you reason about the repository; the sandbox is how an agent changes it. They share the credential, so one connection underwrites both, but a question you ask in chat reads your repository, it does not rewrite it.

Most teams that are doing code work want both, and because they share the credential, connecting one does most of the work of the other. Set up the repository provider so the platform can reach your code, and the code integration builds on it to make chat aware of that code.

Code-aware chat, in one afternoon

Maya's team has the orcette/insights repository connected through their GitHub App, and an admin has wired the GitHub code integration on top. Maya did nothing extra: she had already authorized the App as @maya for the repository provider, and because the integration builds on that same credential, her code-aware chat resolves as her.

A pull request she opened that morning, #142, is showing a red check. She opens chat from the plan she is working against and asks why it is failing. The agent reads the run and the diff, tells her the lint check failed on two files, names the lines, and notes both are in #142. She fixes them without leaving the conversation.

An hour later her lead asks, in the same workspace, what is left before the import work can ship. The lead is not in the code, but the agent is: it lists the open pull requests against that work and reads where each one stands, then answers from what it finds rather than asking the lead to go check GitHub. Two different people, two different questions, one connection, and neither of them tabbed over to GitHub to get a grounded answer.

Permissions

Wiring the GitHub code integration for the workspace is admin work, held by integrations.manage, the same scope that gates the Azure DevOps integration. Connecting your own GitHub credential on top is yours, governed the same way the repository provider credential is, so an admin wires the integration once and each person brings their own GitHub access.

As with every connection, the wiring step is recorded on the audit trail as a configuration change, and connecting your credential is recorded as an authorization event against you. The agent's reach through code-aware chat is bounded by your credential and recorded against the person who set it up, so a security review can answer who could reach what, and through whose access.

When the connection is not behaving

Code-aware chat leans on three pieces, so when it is not doing what you expect, the piece that is off is usually the one to check:

• The credential shows "Token not compatible." The connected credential is a classic ghp_ token, which cannot drive Copilot. Connect a fine-grained token or use App OAuth on the repository provider, or run code-aware chat on a non-Copilot runtime, and the flag clears.
• The agent answers in generalities, not from the repository. The GitHub tools are most likely off, or your personal credential is not connected and there is no workspace default to fall back on. Open the integration, confirm the tools are on, and check that your credential resolves under "Your credential."
• The agent reaches the wrong repository, or none at all. Awareness follows the repository provider the integration is built on. Confirm the provider points at the repository you mean and that the credential can reach it; the provider's own Test Connection is the fastest way to prove the credential reaches the code before you ask the agent about it.

Why code-aware chat works this way

An agent that talks about code without being able to read yours is a confident stranger. It will tell you how pull requests tend to fail and how a function like yours is typically used, and it will be wrong on your repository often enough that you stop trusting it on the cases that matter. The code integration closes that gap by binding the three things an agent needs to be useful about your repository, the access to reach it, the tools to read it, and a runtime tuned for code, into one connection, so the agent reasons from your repository instead of around it. The reason it is a composition rather than a monolith is that the pieces are useful on their own and better together: the provider already exists for cloning, the MCP layer already governs tools, and the integration just makes them act as one.

For a planner, code-aware chat is how a question about the state of the work gets a real answer without a tap on an engineer's shoulder. You ask what is blocking a pull request or what is left before a change ships, and the agent reads GitHub and tells you, in the same conversation where you are shaping the plan.

For an engineer, it is the agent finally having the context you have: the actual diff, the real check run, the way a function is used across the service. The help is grounded in the repository in front of you, so it is worth taking rather than worth double-checking.

For a lead, the value is that you do not have to teach your team when to trust the agent and when to second-guess it. Because its answers come from the live repository rather than a guess about code in general, "ask the agent" becomes a reliable first move instead of a coin flip, and the time your engineers used to spend verifying its claims goes back into the work.

For the person who has to sign off on connecting it, the boundary is the credential, and it is the one your team already governs. Code-aware chat reaches exactly what the connected GitHub credential can reach, a call at a time through the same approved-actions controls as any tool, recorded against the person who connected it. The integration adds awareness, not reach.