How to automatically fix GitHub issues with an AI agent

Every repo accumulates issues that are perfectly clear and permanently unscheduled. The bug with exact repro steps that nobody has an afternoon for. The good first issue that has been open since March. You can now have an AI fix GitHub issues like these end to end: add a label to the issue, and an agent checks out your repo in a sandbox, writes the fix, runs your tests, and leaves you a pull request to review.

This post shows the workflow as Sinatra runs it, then gets specific about which issues delegate well, which don't, and the guardrails that make it safe on a repo you care about.

The label-driven workflow

There is one piece of setup. You connect Sinatra to GitHub and enable the repos you want it to work in. Sinatra provisions its label on each enabled repo, so it shows up in the label picker like any other label.

From then on, delegating an issue is a single action: add the Sinatra label. The issue is the spec, so it's worth ten seconds to check that the title and description say what done looks like. "CSV export is off by one hour, repro steps below, times should match what the UI shows" will go much better than "export is broken."

Once the label is on, here is what happens:

1. The agent starts an isolated sandbox and checks out your repository into it. Nothing runs on your machine, and nothing touches your default branch.
2. It reads the parts of the codebase the issue touches and posts progress as comments on the issue, so you can see what it's doing without going anywhere. If the issue is vague, it works out the requirements first and posts them for your approval before writing code.
3. It creates a branch, opens a draft pull request linked to the issue, and makes the change.
4. It runs the test command you configured and fixes anything the tests catch, then reviews its own diff and marks the PR ready for your review.

From there it's a normal code review. If the PR is good, merge it. If it isn't, leave a review comment ("this should reuse the existing date helper," say) and the agent pushes a revision to the same branch. When the PR merges, the issue closes.

The behavior is per-repo config: a .sinatrarc.json checked into the repo sets the model, the test command, and which phases run. The docs cover the options.

Which GitHub issues an AI can fix well

The issues that auto-fix well share one property: the issue text plus the repo is everything the fix requires.

• Reproducible bugs. A stack trace, exact repro steps, or a failing test narrows the search to something an agent resolves reliably. This is the best category to start with.
• Small, bounded features. "Add a --json flag to the export command" is a diff you can predict before you read it.
• Missing tests. The behavior already exists in the code; the issue just names the module and the cases worth covering.
• Mechanical refactors. Renames, or replacing a deprecated pattern everywhere it appears. Tedious for a person, mechanical for an agent.

And the issues that don't:

• No reproduction. "The app is sometimes slow" gives an agent nothing to bisect. You'll get a plausible guess, not a fix.
• Design decisions. If the issue is really a question ("should notification settings be per-user or per-org?"), a pull request is the wrong output. Decide first, then delegate the decided thing.
• Anything that needs production data or access. The agent works in a sandbox with your repo, not with your production systems. An issue that can only be diagnosed against live data isn't delegable, and shouldn't be.

A useful test before labeling: could a contractor with repo access, who has never met your team, do this from the issue text alone? If yes, label it.

The guardrails

The pull request is the gate. The agent's work lands as a PR on a branch, and nothing reaches your default branch until a person reviews and merges it. Your branch protections apply the same way they do to any teammate.

Scope stays on the issue. One labeled issue produces one focused PR. The agent doesn't wander into drive-by refactors or open side quests in other parts of the repo. If it thinks the issue implies more work, that belongs in the PR description or an issue comment, where you can decide.

Tests gate the review request, not PR creation. The draft PR exists while the agent is still working; what your test command finds in the sandbox decides when the PR gets marked ready. If CI fails after that, the agent reads the failure and pushes fixes to its own branch. A red build is the agent's problem before it's yours.

Other tools do this too

The label-and-assign pattern isn't unique to Sinatra. GitHub's own Copilot coding agent (GitHub's docs now call it Copilot cloud agent) does the assignment version: you set Copilot as an issue's assignee on the paid Copilot plans, it works in a GitHub Actions environment, and it opens a pull request for review (GitHub's docs). The pattern is spreading because it fits how teams work: the issue tracker is already the queue.

Where tools differ is everything around the loop: whether you bring your own model and keys, how the sandbox is isolated, how the revision loop works, and what the agent does when a ticket is underspecified. We keep a fuller picture of how Sinatra handles the GitHub side at /use-cases/github-issues-to-prs, and the original walkthrough of the whole loop is in our first post.

The cheapest way to find out whether this fits your backlog is one issue. Pick a bug with repro steps, add the label, and read the PR that comes back. You can start for free, or read the docs to set up your repo first.