GitHub issue to pull request automation: every option in 2026

GitHub issue to pull request automation used to mean one thing: a scheduled workflow that regenerated some files and opened a PR nobody read. In 2026 it means a range, from a 30-line YAML file that commits templated changes to an autonomous agent that reads the issue, writes the fix, runs your tests, and asks for review. The right choice depends on how much understanding the change requires, and the honest answer is different for different issues in the same backlog.

This is a roundup of every serious option, ordered from scripted to autonomous.

Product details checked August 2026. Vendors change; check their docs for current specifics.

GitHub Actions and scripted PRs

The oldest option is still the best one for a whole class of work. A workflow triggers on an event (a label, a schedule, a push), runs a script that changes files, and hands the result to an action like peter-evans/create-pull-request, which commits the changes and opens the PR. The action is on its eighth major version, actively maintained, and has been the standard way to do this for years.

The key property: the script decides what changes, so the output is deterministic. That makes it the right tool when the change is templated and the issue is only a trigger. Dependency bumps, regenerating code from a schema, syncing a changelog, formatting sweeps. It is the wrong tool the moment the change requires reading the issue and understanding the code, because the workflow does neither. You wrote the fix in advance; the automation just delivers it.

Cost is Actions minutes, and debugging is ordinary CI debugging. If your issue backlog contains recurring, predictable changes, this option never embarrasses you.

GitHub Copilot coding agent

GitHub's own agent (its docs have started calling it Copilot cloud agent) is the lowest-friction way to point AI at an issue if you're already paying for Copilot. You assign the issue to Copilot the way you'd assign a person: open the assignees list, pick Copilot, optionally add guidance. It works in an ephemeral GitHub Actions environment where it can explore the code, make changes, and run tests, then opens a pull request for your review (GitHub's docs).

The strengths are the obvious ones: there's nothing new to onboard, and batch-assigning a backlog of small issues is genuinely convenient. The tradeoffs are platform-shaped. It's available on the paid Copilot plans, the execution environment is GitHub Actions, and the model menu is what GitHub offers. If your team lives entirely inside GitHub and already has Copilot seats, it's the natural default to test first.

OpenHands

OpenHands is the open-source path, and it has the most direct issue trigger of the agent options: on OpenHands Cloud with the GitHub integration installed, you label an issue openhands or mention @openhands in a comment, and the agent picks it up, comments with a link to its session, and opens a pull request if it resolves the issue (OpenHands docs). Because the core is open source, you can also run the agent yourself and bring your own model keys, which puts the operational work (and the token bill) on your side.

Open source buys you control and model freedom, and costs you operations. Running an agent fleet is real infrastructure work: sandboxing, credential handling, upgrades, monitoring. Their cloud removes that at the price of another hosted service. It's the strongest option for teams that want to inspect or modify the agent itself.

Devin

Devin (from Cognition) is the most session-shaped of the group. Its GitHub integration is about the output side of the loop: connect it to your organization and Devin can create pull requests, respond to PR comments, and work inside your repositories (Devin's docs). The trigger side is different from the others here: the documentation describes starting sessions from the Devin app (where you can @mention repositories in prompts) and via its API, not from a GitHub issue directly. If you want issue-driven Devin, you paste the issue into a session or wire the API to your issue events yourself.

That shape fits how Devin is positioned: longer supervised sessions on larger tasks rather than fire-and-forget tickets. For "label an issue, get a PR" it's the most indirect of the options; for "work through this migration with oversight" it's the most natural.

Sinatra

Sinatra (that's us) is built specifically around the issue-to-PR loop. On GitHub, you add the Sinatra label to an issue. The agent starts an isolated sandbox, checks out the repo, and makes the change on a branch; progress lands as comments on the issue, and the pull request opens as a draft while the work is still in flight. It runs the test command you configured and reviews its own diff, then marks the PR ready for you. Review comments on the PR turn into revisions on the same branch, and the issue closes when the PR merges. If the issue is vague, it posts its understanding of the requirements for approval before writing code.

The distinguishing choices are the review loop and the economics. You bring your own Anthropic or OpenRouter key, or connect a ChatGPT subscription you already pay for, and there's no markup on tokens; the free tier is 5 tasks a day on your own key, and the paid plan is $20 per member per month. Model and behavior are per-repo config. We wrote up the workflow in detail in how to automatically fix GitHub issues with an AI agent, and the product page is at /use-cases/github-issues-to-prs.

GitHub issue to pull request automation, compared

Option	How an issue triggers it	Setup effort	What it can handle	Cost model
Actions + create-pull-request	Workflow event: label, schedule, push	One YAML file, plus the script that makes the change	Templated, predictable changes only	GitHub Actions minutes
Copilot coding agent	Assign the issue to Copilot	Minutes, if you have Copilot seats	Small to medium changes in-repo	Paid Copilot plans
OpenHands	openhands label or @openhands mention (cloud)	Install the integration, or self-host the stack	Issue-driven fixes; depends on the model you bring	Open source self-hosted (your models, your ops) or their cloud
Devin	No direct issue trigger documented; sessions start from the app or API	Connect the GitHub integration, then wire your own trigger	Longer supervised sessions and larger tasks	See vendor pricing
Sinatra	Add the Sinatra label	Connect repos; optional .sinatrarc.json	Well-specified issues end to end, with a revision loop	Free tier (5 tasks/day BYOK); $20/member/month; no token markup

When each one fits

Use Actions when the change is knowable in advance. If you can write the script, write the script. Deterministic automation doesn't hallucinate, and it costs almost nothing to run. Most teams should keep this layer even after adopting an agent.

Use Copilot coding agent when you're already inside the GitHub and Copilot ecosystem and want the shortest path to trying agent-written PRs. Assigning a few backlog issues costs you nothing but the seats you already pay for.

Use OpenHands when control matters more than convenience: you want to read the agent's code, run it on your own infrastructure, or pick models the hosted vendors don't offer, and you have the engineering appetite to operate it.

Use Devin when the work is bigger than an issue: migrations and multi-step projects where you want to supervise a session rather than review a finished PR.

Use Sinatra when the backlog is the problem: a steady stream of well-specified issues you want turned into reviewable PRs without a person context-switching for each one, on models and keys you control.

The categories overlap less than the marketing suggests. A scripted workflow and an autonomous agent aren't competitors; they're different answers to "how much does this change require understanding?" Most teams end up with a scripted layer for the predictable work and one agent for the rest.

Common questions

Can GitHub Actions alone turn an issue into a pull request?

Yes, if the change is templated. A workflow can trigger on an issue label, run a script, and open a PR with create-pull-request. What Actions alone can't do is read the issue and decide what code to write. The moment the fix requires understanding, you need an agent on top, or a person.

Do any of these merge their own pull requests?

No. All five options end in a pull request on a branch, so your review process and branch protections apply. In Sinatra's case this is explicit policy: the PR is the gate, and nothing reaches your default branch until a person merges it. Whatever tool you pick, keep it that way.

What's the cheapest way to do this?

For templated changes, Actions: minutes are cheap and there's no model involved. For agent work, the biggest cost variable is token pricing. Tools that bill you for models at a markup cost more at volume than bring-your-own-key pricing, where you pay your provider directly. That comparison is worth running on your own numbers before you standardize on anything.

What about issues that aren't well specified?

Fix the issue text first; every option here does better with a clear spec, and the scripted options require one by definition. Agents differ in how they fail: some guess, some ask. When a ticket is vague, Sinatra posts its understanding of the requirements as a comment for approval before it writes code, which turns a bad ticket into a short conversation instead of a wrong PR.

If your backlog has both kinds of work, start at both ends: script the change you can predict, and hand one well-specified issue to an agent. You can start for free, or read the docs to see the setup before you commit.