Quick answer
GitHub announced its Copilot cloud-agent integration for Linear on July 23, 2026. A user can assign a Linear issue to Copilot; the agent works in an ephemeral GitHub Actions environment, opens a draft pull request, reports progress back to Linear, and asks for review when it finishes. That is useful for bounded maintenance work, but it should not turn every backlog ticket into an autonomous coding job.
Use the integration for one repository, one small issue, one branch, and one reviewable draft PR. Put the acceptance criteria and test command in Linear before assignment. Keep deployment, credentials, payment, permission changes, broad refactors, and unclear product decisions human-owned. If the task does not pass the review gates, return it to the ordinary Linear-to-human workflow rather than widening the agent's access.
Who this is for
This checklist is for an indie developer or a small product team that uses Linear for planning and GitHub for review. A human still owns repository settings, issue definition, merge, and production release. It is distinct from GitHub Issue agent automation, which governs GitHub-Issue triage rather than a Linear-to-PR handoff.
What changed, and the important boundary
GitHub's July 23 changelog calls the Linear integration generally available. It says the integration can select a model or a repository custom agent, set base and working branches, and accept steering comments from Linear. The GitHub App listing still labels the app "Public preview" at the time of writing. Treat the product label as less important than the actual access check: confirm that your workspace, GitHub organization, repository, and individual account can perform the intended handoff.
The most important operational boundary is easy to miss. GitHub's cloud-agent documentation says third-party integrations such as Linear support creating a pull request directly; the research, planning, and iterate-before-PR flow is available on GitHub.com, not through an external integration. Write a complete task brief before assignment. Do not expect an ambiguous Linear ticket to become a safe discovery session.
The agent runs in an ephemeral Actions-powered environment. It works on one repository and one branch at a time, opens one PR per task, and has a hard 59-minute execution limit. Multi-repository, production, or open-ended design work is not a first candidate.
Choose the first issues deliberately
Start with small work that produces evidence without requiring privileged context.
| Linear issue shape | First-run decision | Evidence that must be attached |
|---|---|---|
| Reproducible bug with a focused test | Good candidate | Reproduction, expected behavior, test command |
| Documentation correction with an owner-approved source | Good candidate | Source link, files allowed to change, preview check |
| Small refactor behind a stable contract | Canary only | Contract test, explicit non-goals, rollback note |
| Cross-repository change or migration | Keep human-owned | Dependency plan and named owner |
| Deploy, secret, billing, auth, or permission change | Never delegate through this flow | Human approval and separate runbook |
| Vague feature request | Clarify first | Acceptance criteria before assignment |
The point is not to find work that looks easy in a title. It is to find work whose completion can be disproved by a test, a diff review, or a documentation preview. A vague issue produces a vague draft PR, then moves the specification work into code review where it is more expensive to correct.
Use a reviewable Linear intake
Before assigning Copilot, make the Linear issue self-contained. The following is a writing template, not a Linear schema or a Copilot configuration file.
Goal:
Repository:
Allowed paths:
Do not change:
Acceptance test:
Expected result:
Base branch:
Working branch:
Rollback: close the draft PR; no deployment or migration has run
GitHub says installation needs organization-owner permission in GitHub and workspace-admin privilege in Linear; its app listing also says each user must link a GitHub account to Linear. Check those conditions before treating a missing assignment option as an agent failure. For Business and Enterprise, check the cloud-agent policy and repository opt-in too.
Apply six gates before a draft PR becomes work
The agent can open a draft; that does not make the change ready to merge. Use these gates in order.
- Handoff gate. The Linear issue names exactly one repository, intended base branch, bounded paths, and a test. The GitHub and Linear links point to the same work item.
- Scope gate. The draft touches no forbidden surface. If it needs a new secret, broader MCP access, workflow permission, production endpoint, or another repository, stop the run and return to human planning.
- Evidence gate. The PR body or Linear update records the command run, result, and any test that could not run. "Looks correct" is not evidence.
- Diff gate. A reviewer checks that the patch meets the stated behavior and did not silently rewrite unrelated files. A passing test is necessary, not sufficient.
- Cost and time gate. Record agent duration, AI credits, and Actions minutes for accepted PRs. Split tasks that approach the session limit instead of repeatedly reassigning a large ticket.
- Merge gate. Existing CI, code review, and branch-protection rules remain the merge authority. The Linear status should move only after the normal repository policy is satisfied.
GitHub notes that branch protection or rulesets can prevent its cloud agent from creating or updating PRs. Treat that as a repository-policy decision, not a reason to grant a broad bypass. Start with five issues, retain only task types that produce accepted PRs without unresolved review findings, and return failed canaries to the human queue.
Common mistakes
Treating a draft PR as a planning artifact. The Linear integration directly creates a PR. Do the discovery and acceptance-criteria work before assignment, or use GitHub.com's research and planning surfaces first.
Solving a blocked run with more access. A blocked branch rule, missing policy, or unavailable model is a signal to review configuration. It is not evidence that an unbounded bypass is safe.
Measuring only PR count. Track merged outcome, review rework, test result, elapsed time, and credits per accepted change. More drafts can mean more triage rather than more throughput.
FAQ
Does Linear integration give Copilot access to every repository?
No. GitHub says a cloud-agent task works in the repository specified when it starts and cannot make multi-repository changes in one run. Repository owners can also opt repositories out of the agent.
Can the agent research a repository before opening a PR from Linear?
Not through the Linear integration flow. GitHub documents research, planning, and iteration before PR creation on GitHub.com, while external integrations create a PR directly. Put enough context in the Linear issue to make the direct handoff safe.
What should happen when the agent times out or the draft expands in scope?
Do not keep reassigning the same broad ticket. Split it into a smaller, testable issue or move it to the human queue. The documented cloud-agent session limit is 59 minutes, and a single task maps to one branch and one PR.
Top comments (0)