How to assign GitHub issues to an AI coding agent

By the end of this guide you will have taken a real GitHub issue, handed it to an AI coding agent, and reviewed the pull request it opened. To assign GitHub issues to an AI coding agent, you pick a tool that watches your repository, give it a clearly written issue, and let it work in a sandbox or a separate branch while you stay in charge of the merge.

The tools sit in our Coding category and in the agents corner of automation. Some are products you switch on inside GitHub, some are hosted services you connect with a GitHub App, and some are open-source systems you run on your own server. This guide shows how to choose between them and how to run your first issue safely.

Key takeaways

• Write the issue like a brief: the problem, the expected result and how to check it. The agent can only be as clear as the ticket.
• The main decision is where the agent runs: inside GitHub, in a hosted sandbox, or on infrastructure you operate yourself.
• Most tools bring their own limits: GitHub Copilot's free plan excludes the cloud agent, and several tools need your own model key.
• Treat every agent pull request as a draft from a new colleague. Read the diff, run the tests, and keep merging in human hands.

What you need before you start

• A GitHub repository you can change. You need permission to install an app or add a label, and ideally a repository with working tests.
• A small, well-defined issue. Pick a bug or a chore with clear acceptance criteria for your first run, not an architecture change.
• Model access if the tool asks for it. Several tools below need your own Claude, ChatGPT or other API key rather than bundling a model.
• Branch protection. Require a review before merge so nothing the agent writes can land unseen.
• Time. A first run takes under an hour to set up for a hosted tool. Self-hosted options take longer.
• Difficulty. Moderate for hosted tools, harder for anything you deploy and operate yourself.

Which kind of AI tool fits this job

Choose by where you want the work to happen and who should control it.

Built into GitHub. GitHub Copilot lists a cloud agent that works in the background and opens pull requests, alongside code review and chat in the editor. It supports VS Code, Visual Studio, JetBrains, Xcode, Neovim and Eclipse. Its listing says the free plan excludes the cloud agent, so check which plan you need.

A hosted agent you connect with a GitHub App. Sinatra takes work from a GitHub issue label, a Linear issue, a Slack mention or its CLI, runs it in a hosted sandbox, and returns a draft pull request. It also answers eligible review feedback and failing CI checks. Orbi triggers when you label an issue ai-ready, writes the change in a git worktree, runs tests, and has a second AI review the result before merging only the reviewed commit.

A self-hosted worker or platform. OpenHands is an open-source platform whose agents can be triggered from GitHub, GitLab, Slack, Jira or a schedule and run in containerized sandboxes, although isolated sandboxes are not available on the local backend of its open-source Agent Canvas. DevIntern is a daemon you run yourself that watches a tracker such as GitHub Issues or Jira for tickets marked ready, then uses the coding agent you already have. Open SWE is LangChain's MIT-licensed framework for building your own internal coding agent, so it suits teams that want to assemble rather than adopt.

A command-line planner. Wiggum CLI sits on top of CLI agents such as Claude Code and Codex CLI. Its agent mode reads your GitHub issues, orders them by label and dependencies, and runs a loop on each. It is a good fit if you live in the terminal.

Step 1: Choose an issue the agent can finish

A good first task is small, testable and self-contained.

1. Filter your backlog for bugs or chores that touch only a few files.
2. Skip anything that needs a product decision, secrets or a database migration.
3. Confirm the repository has tests the agent can run.
4. Write down in one sentence how you will know it is done.

Check it worked by asking whether a new teammate could finish the ticket without asking you a question.

Step 2: Rewrite the issue as a brief

Agents act on what is written, so the issue is the prompt.

1. State the current behaviour and the behaviour you want.
2. Name the files, modules or commands that matter, and how to run the tests.
3. List what must not change, such as public APIs.
4. Add an acceptance check, for example "the existing test suite passes and the new case is covered".

DevIntern describes a feasibility gate that bounces vague specs back to the ticket. Check it worked by reading the issue as if you had never seen the code.

Step 3: Connect the tool to your repository

You end this step with the agent able to see the repository and nothing else.

1. Install the tool's GitHub App, or follow its self-hosting guide if you run it yourself. Sinatra's setup is done once per workspace by installing the GitHub App.
2. Select only the repositories you want it to touch. Orbi's cloud connects only the repositories you select.
3. Add model access if required. Sinatra and Orbi's self-hosted option both expect your own key or subscription.
4. Turn on branch protection and required reviews in GitHub.

Check it worked by confirming the tool lists your repository and that the agent has no access to others.

Step 4: Trigger the agent on the issue

Each tool has its own trigger, so use the one your chosen product documents.

1. For Orbi, add the ai-ready label to the issue.
2. For Sinatra, add its label to the GitHub issue, or start a task from its CLI.
3. For Open SWE, the original design runs from a label such as open-swe-auto, or from its web interface.
4. For Wiggum CLI, use the --issue flag or its GitHub issue picker.
5. For GitHub Copilot, delegate the issue to the cloud agent as described in its documentation.

Check it worked by seeing a branch, a draft pull request or a status comment appear on the issue.

Step 5: Watch the run and answer questions

Most agents plan before they code, and some let you approve or edit that plan.

1. Open the tool's dashboard or the pull request to follow progress.
2. If the tool offers a plan step, read it. Open SWE lets you accept, edit or reject the plan.
3. Reply to clarifying questions in the issue rather than editing code yourself.
4. Stop the run if the plan drifts from your brief and tighten the issue.

Check it worked by seeing the plan name the same files and checks you expected.

Step 6: Review the pull request like any other

The agent's job ends at the pull request. Yours starts there.

1. Read the full diff, not just the summary the agent writes.
2. Run the tests locally or confirm CI is green. Orbi says release test acceptance depends on your own CI results.
3. Look for unrelated edits, deleted tests and new dependencies.
4. Leave review comments. Sinatra replies to eligible review feedback, and DevIntern turns reviewer comments into commits on the same branch.
5. Have a person with the right knowledge check anything touching security, payments or personal data.

Check it worked by being able to explain every changed line to a colleague.

Step 7: Merge, then refine your process

Merging stays with you in the tools that state it.

1. Merge only after review and passing checks. Sinatra's listing says merging stays with you.
2. Note what the agent got wrong and add it to your next issue template.
3. Run a second, slightly bigger issue before you widen access.

Check it worked by comparing the time spent writing the brief and reviewing against doing the change yourself.

Tools for this job compared

Tool	Good fit for	Pricing	Stated limits
GitHub Copilot	Delegating issues from inside GitHub and your editor	Freemium, paid from $10/mo (checked 23 Oct 2026)	Free plan excludes the cloud agent and code review; usage beyond included credits costs extra
Sinatra	Hosted agent from GitHub, Linear or Slack	Freemium, paid from $20/mo (checked 24 Oct 2026)	Needs your own model subscription or key; Free plan runs 1 task at a time, up to 60 minutes per request
OpenHands	Teams wanting sandboxed, self-hosted agents	Freemium, paid from $499/mo (checked 24 Oct 2026)	Teams plan capped at 5,000 sessions a month; isolated sandboxes not on the local Agent Canvas backend
Orbi	Labelled issues to reviewed, merged pull requests	Freemium, paid from $24/mo (checked 24 Oct 2026)	Solo connects 1 repository, Pro up to 5; deliveries pause when the token allowance runs out
DevIntern	Draining a ticket backlog from Jira, Linear or GitHub Issues	Freemium, paid from $99/mo (checked 24 Oct 2026)	You run the worker yourself; unattended automation needs a paid license
Wiggum CLI	Terminal users working through a GitHub backlog	Freemium, paid from $19/mo (checked 24 Oct 2026)	Needs your own API keys and a CLI coding agent; Pro plans are on a waitlist
Open SWE	Teams building an internal coding agent	Open source	Under active development with breaking changes expected; you deploy it and supply a model key

Prices and plan limits change, so confirm the current terms on each vendor's site before you subscribe.

Common mistakes to avoid

• Assigning a vague issue. Agents guess when the ticket is unclear, and a guess becomes a confident but wrong pull request. Fix it by writing the expected behaviour and a check before you trigger anything.
• Letting the agent merge unseen. Automated merging is tempting when the tests pass, but tests only cover what someone thought to test. Fix it by requiring a human review in branch protection.
• Giving broad repository access. An app installed on every repository can touch code you never meant to include. Fix it by selecting only the repositories involved, as Orbi's cloud setup encourages.
• Starting with a big task. Open SWE's own listing notes its multi-stage plan and review design is not ideal for one-line fixes, and large changes are harder to review. Fix it by matching the tool and the task size.
• Ignoring model costs. Several tools bill orchestration separately from model usage, so your own provider account carries the token bill. Fix it by checking who pays for the model before you queue a backlog.

How we put this together

This is an evidence-based guide built from each tool's listing in our directory, which is compiled from the vendor's own site and pricing page. It is not a review based on using the tools. We don't rank tools, and nobody paid to be included. Some outbound links may be affiliate links; see our disclosure.

Frequently asked questions

Can an AI agent really fix a GitHub issue on its own?

It can produce a pull request for a well-described issue, but it is not guaranteed to be correct. Sinatra, for example, plans the change, runs your tests and opens a pull request, and its listing says merging stays with you. Orbi merges the reviewed commit itself, though it lists an optional approving review via branch protection. Review the diff before it lands.

Is there a free way to try this?

Yes, in places. Sinatra has a Free plan that runs one task at a time, and Wiggum CLI's core is free and self-hosted with your own API keys. OpenHands offers a free self-hosted Agent Canvas, and Orbi's self-hosted core costs US$0 with your own model key. GitHub Copilot has a free plan, but it excludes the cloud agent.

Can I keep my code private?

Self-hosting keeps the runtime on your infrastructure. OpenHands, Orbi, DevIntern and Open SWE can all be self-hosted, though your code still goes to whichever model provider you configure. Read each vendor's data terms before you connect a private repository.

Which kind of issue works best for a first try?

A small bug or chore with clear steps to reproduce and an existing test. Avoid anything needing a product decision or sensitive credentials until you trust the workflow.

Do I still need to review the code?

Yes. DevIntern's listing says output still needs human review before merge. Treat the agent's pull request like one from a new contributor.

Compare more options in our Coding category.