GitHub Copilot’s Cloud Agent With Azure Boards

Yes, GitHub Copilot’s agent works with Azure DevOps, through Azure Boards. Open a work item, select the GitHub icon, choose Create a pull request with GitHub Copilot, pick a GitHub repository and branch, and Copilot’s cloud agent writes the change and opens a draft pull request, which Azure Boards links back to the work item and tracks with a status. The catch is where the code lives: the repository has to be on GitHub. Azure Repos is not supported, and the connection between the two must use the Azure Boards GitHub App, not a personal access token. If your code is in Azure Repos, or you want Copilot to read and update work items rather than write code from them, the Azure DevOps MCP server is the route instead.

On names: GitHub now calls the agent the Copilot cloud agent, and it was previously the coding agent. Microsoft’s pages still use both. They are the same agent, and how it works on GitHub is in the GitHub Copilot coding agent.

What you need

Microsoft’s guide to using GitHub Copilot with Azure Boards↗ (opens in a new tab) is written for Azure DevOps Services, the cloud version, and lists the requirements:

• A GitHub Copilot subscription for the person starting it. GitHub’s side says a paid Copilot plan, with the cloud agent enabled for the connected repositories; on Business and Enterprise plans an administrator has to switch it on.
• A repository hosted on GitHub, with access to the branches you will target. Azure Repos repositories do not appear in the list.
• Azure Boards connected to GitHub through the GitHub App. Personal access token connections are not supported for this.
• Contribute permission on the work items in Azure DevOps, and the right to link artifacts to them.
• A work item type in the Requirements or Task category: User Story, Product Backlog Item, Requirement, Task, Bug and Issue all qualify, as do custom types mapped to those categories, in Agile, Scrum, CMMI or custom processes.

Setting it up

1. Install the Azure Boards app on your GitHub account or organisation and grant it the repositories you want, following Connect Azure Boards to GitHub↗ (opens in a new tab). A project can link up to 2,000 GitHub repositories per connection.
2. If the app was installed before the Copilot integration existed, accept its updated permissions: in GitHub, open your installed apps, find Azure Boards and select Review request.
3. Make sure the cloud agent is enabled for those repositories, and that each person who will use it has a Copilot licence.
4. Optionally, give the repository what the agent needs to work well: an instructions file, and a copilot-setup-steps.yml workflow that installs dependencies before it starts.

Starting Copilot from a work item

1. Open the work item and select the GitHub icon in the form. If there are several GitHub actions, it is a dropdown.
2. Choose Create a pull request with GitHub Copilot.
3. Pick the GitHub repository and the base branch.
4. Optionally pick a custom agent. Since the Sprint 269 update↗ (opens in a new tab), agents defined at repository or organisation level in GitHub appear in a selector next to the repository list; writing one is covered in GitHub Copilot custom agent examples.
5. Optionally add instructions, such as “add unit tests for new logic” or “follow the existing naming conventions”, and select Create.

What gets sent to GitHub

Microsoft says Copilot receives the work item’s title, its large text fields such as description and acceptance criteria, its comments, and a link back to it. GitHub’s page on integrating the cloud agent with Azure Boards↗ (opens in a new tab) is more precise about comments, the last 50, and adds a point worth acting on: that context is stored in the pull request, where anyone with access to the repository can see it.

So a work item is now also a prompt with a wider audience than your board. Keep credentials, customer details and anything else that should not be in the repository out of the description and comments of items you hand to Copilot. And because only those fields travel, links, attachments and related items do not: if the agent needs it, write it into the description.

While it runs, and after

• Status on the work item: In Progress while Copilot writes code, Ready for Review when the draft pull request is ready, Error if it failed, with details on hover. Microsoft expects a run to take 5 to 15 minutes.
• On the board: a Copilot icon on the card, so you can see which items have a run going or finished without opening them.
• In the Development section: the branch Copilot created, the draft pull request and its status, and a link to the code on GitHub.
• Review happens on GitHub. Convert the draft to a regular pull request when you are happy, review and approve it there, and merge. The merge commit links to the work item and the Copilot status disappears.
• The work item does not move itself. Updating its state and closing it are still yours to do.

Limits to plan around

• No cancel. Once started, a run cannot be stopped from the work item; you close or discard the pull request it produces.
• Straight to a pull request. GitHub’s cloud agent overview↗ (opens in a new tab) notes that integrations such as Azure Boards, Jira and Linear only support creating a pull request directly, without the research-and-plan step available when you start the agent on GitHub.
• One repository, one branch and one pull request per run, and a session limit of 59 minutes. A work item that spans two repositories needs two items.
• No dependencies. Copilot does not read related work items, so each one has to stand alone.
• Rerun, not continue. If it fails, Rerun Copilot tries again with the same or new instructions; you can also fix the branch by hand.
• Cost. The cloud agent uses GitHub Actions minutes and AI credits, counted against your GitHub plan, not your Azure DevOps one.

Microsoft’s best practices say the rest: short, specific work items with clear acceptance criteria get better results than long ones. The same habits apply to any task for an agent, and how to write a task for an AI agent goes through them.

The other route: the Azure DevOps MCP server

The Boards integration runs one way: a work item goes in, a pull request comes out. If you want Copilot to read your backlog, summarise an iteration, or add comments and links to work items, you need Azure DevOps as a set of tools, which is what Microsoft’s Azure DevOps MCP server provides. It also works when your code is in Azure Repos. Setting it up in VS Code, Claude Code or Cursor is covered step by step in the Azure DevOps MCP server.

The cloud agent can use it too, with a caveat. It cannot sign in to remote MCP servers that use OAuth, so the hosted Azure DevOps server is out, and GitHub’s page on configuring MCP servers↗ (opens in a new tab) runs the local npm package instead: an Entra application trusted by GitHub over OpenID Connect, an Azure login step in copilot-setup-steps.yml with AZURE_CLIENT_ID and AZURE_TENANT_ID as Agents secrets, and this in the repository’s MCP settings:

{
  "mcpServers": {
    "ado": {
      "type": "local",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "contoso", "-a", "azcli", "-d", "core", "work-items"],
      "tools": ["core_list_projects", "wit_work_item"]
    }
  }
}

GitHub’s own example lists tools such as wit_get_work_item, which were the names before Microsoft consolidated the server’s tools; current versions group reads under wit_work_item. Check the tool list for the version you install, and keep it to read tools: the cloud agent uses a configured server’s tools without asking first.

Which one to use

• Code on GitHub, a well-described work item, and you want a pull request: the Boards integration. It needs no MCP setup at all.
• Code in Azure Repos: the MCP server with Copilot in your editor. The Boards integration will not list your repositories.
• You want the agent to read or update work items, not just be started from one: the MCP server.
• Both: start runs from Boards, and give the cloud agent read access to work items over MCP so it can look up related items the integration does not send.

If the work list is not in Azure Boards

Some teams use Azure Boards because it came with Azure DevOps, not because they need its process templates. If what you want is a plain list of features, enhancements and bugs that people outside engineering can use too, fenbs is a board with four lanes, To Do, Next Up, In Progress and Completed, where an AI assistant is a member with its own role and every change is recorded under its name. It has no sprints, epics, due dates or assignee field, and it does not import from Azure Boards, so moving means recreating the open items, which a pasted list covers for a small board. There is no button that starts the cloud agent from a task either: the cloud agent reaches the board over MCP with a hand-issued token, and a task reference in the GitHub issue ties the two together, as the coding agent post sets out.