copilot cloud agent for linear is ga now: assign the ticket, get the draft pr
GitHub made Copilot cloud agent for Linear generally available on July 23, 2026. Linear issues can be assigned to Copilot, which analyzes the issue, works in an ephemeral GitHub Actions environment, opens a draft pull request, streams progress back to Linear, and requests review when done. Teams can set the model, base branch, working branch, and custom agent per issue or workspace.
GitHub made Copilot cloud agent for Linear generally available on July 23, 2026. the workflow is direct: assign a Linear issue to Copilot, and Copilot analyzes the ticket, works in its own ephemeral GitHub Actions development environment, opens a draft pull request, streams progress back into the Linear activity timeline, then asks for review when the work is complete.
this is the quiet but important shape of agentic development in 2026: the issue tracker becomes the dispatch surface, not the IDE prompt box. the developer still reviews the PR. the agent gets a ticket, repo access, a disposable environment, and enough workflow glue to keep the rest of the team informed.
what teams can control
GitHub says Linear users can choose which model Copilot uses, point it at a custom agent from the repository, set the base branch and working branch, and steer an active session by mentioning Copilot in a Linear comment. those controls can be set per issue or across a workspace or team through Linear agent guidance.
access is available for Copilot Pro, Pro+, Business, and Enterprise. setup requires installing the GitHub Copilot for Linear app from the GitHub Marketplace, with GitHub organization owner permissions and Linear workspace admin privileges.
why it matters
integrations like this are where coding agents stop feeling like demos. a lot of engineering work already starts as a ticket and ends as a pull request. putting the agent in that path means it can pick up small implementation tasks, dependency chores, or cleanup work without a developer manually copying context into chat.
honest take
the boundary is review, not trust. GitHub's adjacent issue automation controls now expose rationale, confidence, and approval flows for some automated issue changes, but GitHub is blunt that approvals are workflow convenience, not a security boundary. same principle here: assign real work, but keep human review on the pull request and treat agent comments as status, not proof.