GitHub gives agents access to issues and runners for assigned work

GitHub gives agents several ways into an issue

GitHub offers a hosted agent, mission control for several agents and an MCP server for agents running elsewhere. Copilot starts when a person assigns it an issue or an automation triggers it on issue creation or a schedule. Those automations are limited to private and internal repos. In Agent HQ, a person assigns the issue to an agent. With the GitHub MCP server, a person runs an MCP client against the repo’s tools.

GitHub renamed Copilot coding agent to Copilot cloud agent on April 1, 2026. It runs on GitHub Actions. It became generally available to paid Copilot subscribers on September 25, 2025.

Agent HQ brings Claude and Codex into GitHub’s assignment workflow. The GitHub MCP server exposes repository tools to an MCP client such as Claude Code, Codex or Cursor, which can run outside GitHub’s hosted sessions.

Assigning an issue starts Copilot with the text available then

To assign an issue to Copilot, select it in the issue’s Assignees menu. Only someone with write access can trigger the agent. The API route adds copilot-swe-agent[bot] as an assignee and is in public preview.

Copilot reads the title, body, existing comments and any extra instructions supplied with the assignment. It does not see comments added afterward. Put the context it needs into the issue before assigning it, as described in GitHub’s assignment docs.

Copilot adds an eyes reaction and opens a linked draft pull request. Under GitHub’s safeguards, it pushes only to its copilot/ branch and cannot mark the pull request ready for review, approve it or merge it. A task covers one repo and one pull request, with an execution time of at most 59 minutes that cannot be extended, according to GitHub’s surface documentation.

Copilot cloud agent automations can start work when an issue is created or on a schedule, on private and internal repositories only. Copilot Free does not include cloud agent. Since June 1, 2026, Copilot billing uses AI credits priced at $0.01 each, as set out in the billing change.

Agent HQ lets you compare Claude and Codex on the same issue

GitHub announced Agent HQ on October 28, 2025, with mission control for assigning, steering and tracking agents. Claude and Codex became available in public preview on Copilot Business and Pro on February 26, 2026. The Agent HQ announcement named agents from Anthropic, OpenAI, Google, Cognition and xAI.

You can assign the same issue to several agents to compare their approaches. That is a documented use of parallel runs, with a person deciding which agents receive the work and comparing what they produce. Mission control gives that person a place to track the sessions.

Third-party agents consume GitHub Actions minutes and AI credits. They are unavailable on Copilot Free and Student. They cannot be steered.

The GitHub MCP server exposes tools to your own agent

The remote GitHub MCP server URL is https://api.githubcopilot.com/mcp/. It has been generally available since September 4, 2025. Authentication uses OAuth 2.1 with PKCE or a personal access token sent as a bearer token, according to the remote server documentation.

You can select a toolset by its path, such as /mcp/x/issues, or use the /readonly suffix for read-only access. The default toolsets are context, repos, issues, pull_requests and users. Claude Code, Codex, Cursor or another MCP client can use the server to read and write issues through those tools.

The github-mcp-server repo lists assign_copilot_to_issue for handing an issue to Copilot and sub_issue_write for changing sub-issues. Issue dependency tools are Insiders only.

For public repositories, lockdown mode withholds issues, pull requests and comments whose authors lack push access. Enable it with --lockdown-mode, GITHUB_LOCKDOWN_MODE or the X-MCP-Lockdown header. GitHub describes it as a best-effort filter against prompt injection and explicitly says it is not an authorization boundary.

Several assignees still need someone to partition the work

A GitHub issue can have up to 10 assignees. GitHub suggests assigning several agents to compare approaches, but documents no claim or lock that keeps them off the same issue. A team that wants exclusive ownership has to arrange it outside that assignment mechanism.

GitHub sub-issues express a parent-child structure with up to 100 sub-issues per parent across eight levels. GitHub issue dependencies allow up to 50 links per relationship type. The links appear in the API and issue_dependencies webhooks. Blocked issues show a Blocked icon. GitHub does not document agents respecting those dependencies, so a blocked issue can still be assigned.

GitHub’s mission control guidance tells you to partition parallel work so agents avoid the same files and merge conflicts. Issue text also comes from anyone allowed to open an issue, including outside filers on a public repo. Assignment, file overlap and which outside text reaches an agent remain decisions your workflow has to make.

GitHub also exposes the graph through webhooks. The issues event fires when an issue is opened, edited, assigned, labeled or closed, among other actions.

A repo connector starts with a signed webhook

An org owner or admin connects a GitHub repo in the Retasc Dash. Choose the project, enter the repo as owner/name and optionally supply an access token. The token needs issues:write, plus pull_requests:write for pull requests.

Retasc stores the token server-side and never shows it back. Without a token, sync is one way. The connector returns a webhook URL and a signing secret shown once, which you paste into the repo’s webhook settings.

GitHub’s signed ping on webhook creation marks the connector as connected in the Dash. Sync issues is on by default, while Sync PRs is off.

An agent acts under a key minted by a signed-in person, with actions attributed to that human and the runtime the agent reports. The human identity comes from GitHub or Google sign-in, never from what the agent says. Run npx @retasc/cli@latest bind in the folder to connect its agent to Retasc’s remote MCP server at https://mcp.retasc.com/mcp.

Outside issues wait for a member to approve the exact text

Retasc verifies X-Hub-Signature-256 as an HMAC-SHA256 over the raw request body, returning the same 401 for an unknown connector, a revoked connector or a bad signature. A replayed delivery is a no-op, deduped by X-GitHub-Delivery. Retasc syncs opened, edited, reopened, labeled, unlabeled, milestoned and demilestoned actions, updating the same issue keyed by github:owner/repo#number and ignoring other actions.

The issue arrives as todo with no priority, which sorts last, and the filer’s GitHub handle as its author. The default support label can be renamed or left blank. A milestone’s due date is ignored, so a filer cannot move work up the queue through a milestone, and a member sets any deadline in Retasc.

No agent is handed the issue until a member approves its exact title and body in the Dash or retasc triage, with approval bound to a digest of that text. The CLI requires an interactive terminal and asks the member to type the issue id after reading the body, with no approve flag or MCP approval tool. An agent key cannot sign off, and an edit on GitHub voids the approval.

When no work is ready, Retasc tells the agent how many issues await sign-off. An agent claiming a synced issue is told who filed it, to evaluate the text as a report and to stop and tell its human if the text asks for credentials, outside systems or to set aside its instructions. On public repos, GitHub’s lockdown mode withholds issues whose authors lack push access, while Retasc’s sign-off lets a member read the text and decide whether to approve it.

Retasc closes the source issue after recording the work

With an access token, done in Retasc closes the GitHub issue with state_reason set to completed. A canceled issue closes with state_reason set to not_planned. Without a token, Retasc cannot send those changes back.

The close runs after Retasc records its own change. If the GitHub close fails, Retasc logs the failure without undoing its own change. A GitHub outage can leave the source issue open after Retasc records the work as done.

Closing an issue on GitHub does not change its Retasc status, and inbound sync changes content only. Revoking the connector stops sync and keeps the issues already imported. The GitLab connector follows the same intake, exact-text sign-off and close-back behavior on gitlab.com and self-hosted GitLab, verifying GitLab’s secret token.

Outside pull requests become review work for a chosen reviewer

Turn on Sync PRs and choose a reviewer to bring outside contributions into the queue. Retasc skips members’ own pull requests. An outside contributor’s pull request becomes review work assigned to the reviewer you chose.

A merged pull request marks its Retasc issue done, while a pull request closed without merging marks it canceled. With a token, Retasc comments on the pull request with the issue it is tracked as.

Retasc dispatches review to a different person’s agent. The server refuses to let whoever sent work to review claim or accept that review. Work sent to review must include its branch, PR or commit unless the agent already left a checkpoint, so the reviewer receives the handoff note.

GitHub can keep the intake while the queue assigns the work

Copilot cloud agent fits when you want to assign an issue and get a draft pull request on GitHub. The GitHub MCP server fits when your agent works with GitHub issues over MCP. Retasc fits when several agents on different runtimes take the next unblocked issue themselves through next_issue. With GitHub and Retasc connected, people keep filing issues on GitHub. Retasc hands out a synced issue only after a member approves its exact text.

A claim is one server transaction. Two agents can never hold the same issue. The agent records a checkpoint of what is done, what is next and the gotchas, which stays on the issue for whoever claims it next.

Blocked work is never handed out. When a blocker closes, its dependents join the queue. A blocker inherits the urgency of the work it holds up, so a chore blocking an urgent feature jumps the queue.

An agent renews its 30-minute lease by heartbeat or checkpoint. When renewal stops because a process dies, a laptop closes or a terminal is killed, the reclaimer returns the issue to its owner’s lane for that person’s next agent, on any runtime, to resume from the checkpoint. A lane nobody returns to rejoins the shared pool after 7 days.

Common questions

Run the command in your repo folder so your agents pull the next unblocked issue from Retasc while people keep filing on GitHub. A new org gets $10 of usage at signup, no card.