Pulling a GitHub issue into Aider: from URL to first commit

Published 2026-05-11 by Owner

There are two ways to give Aider context about a GitHub issue. The first is copy-paste: grab the issue title, the description, maybe a few comments, and drop them into the chat. The second is to pull the issue directly — either by URL or with gh issue view — and let Aider read the full thread. The difference matters more than it sounds.

How the workflow runs

Start a session in your repo directory:

aider

Inside the Aider prompt, add the issue URL as context:

/web https://github.com/your-org/your-repo/issues/42

Aider fetches the issue page, reads the title, description, and every comment. That full thread is now in context. From there, ask for a plan before any edits:

Read that issue and propose a plan before touching any files.

Aider will outline what it intends to do — which files, what changes, what order. Review the plan. If the approach looks right, confirm and it executes. If one step is wrong, say so and Aider revises before proceeding.

If you prefer to stay in the terminal rather than pasting URLs, gh issue view pipes the issue into context cleanly:

gh issue view 42 | aider --message "Read this issue and propose a plan."

Either path lands in the same place: Aider has the full issue thread in context and is waiting for your confirmation before writing code.

One refinement worth adding: once Aider proposes a plan, explicitly add the relevant files to context before telling it to proceed. Aider will often identify them itself, but confirming the file list — and adding any it missed — prevents the session from drifting into editing files outside the intended scope.

/add src/lib/user.ts src/components/Profile.tsx

Then confirm the plan and let it run. This two-step — plan, then file-add, then execute — produces cleaner diffs than jumping straight from issue to execution.

When reading the full issue thread beats copy-paste

For simple issues — a bug with a clear repro and no discussion — copy-paste is fine. The issue body has everything Aider needs.

The pattern where fetching the thread earns its cost is when the comments change the scope. An issue filed as “Button click doesn’t work” might have a comment from the reporter three days later: “Actually it only fails when the user has no profile photo set.” And a reply from a maintainer: “Confirmed — looks like user.avatar_url is null and we’re calling .replace() on it.” That thread context is the bug. The description alone sends Aider in the wrong direction.

Issues that reference specific files are another case. A bug report that says “the error happens in src/lib/user.ts around line 80” gives Aider a starting point. The gh issue view approach preserves those references exactly; manual copy-paste often strips formatting or loses context about what the reporter pasted.

The comment history also matters when a prior fix attempt was reverted. If someone already tried one approach and closed the PR after it caused regressions, that’s context worth keeping. Aider reading the thread means it knows what was already tried.

There’s a practical limit here. Issues with very long comment threads — 50+ replies where scope shifted repeatedly — can confuse the model rather than help it. The thread is large and the signal-to-noise ratio is low. In those cases, summarize the final agreed-upon approach in a fresh comment before pulling the issue into Aider. One clear “we decided to do X, not Y” comment at the bottom of a noisy thread is worth more than 40 comments of deliberation.

Tagging the commit with the issue reference

GitHub closes issues automatically when a commit message on the default branch contains Fixes #123, Closes #123, or Resolves #123. Aider can include this in every commit — just tell it to:

When you commit, include "Fixes #42" in the commit message.

Or set the expectation at the start of the session:

We're working on issue #42. Tag all commits with "Fixes #42".

Aider’s commit messages are editable before they land. The default message it generates often describes what changed; appending the issue reference to that description gives you a commit history that links back to the original context automatically.

For repos that use conventional commits, the pattern looks like:

fix(auth): handle null avatar_url in profile lookup

Fixes #42

Aider will follow that format if your repo has a commit convention in context — either via .aider.conf.yml, a CONTRIBUTING.md it has read, or explicit instruction in the session.

If you want the issue reference on every commit Aider makes during the session — not just the final one — set that expectation once at the top:

For this entire session, append "Refs #42" to every commit message.
Use "Fixes #42" on the final commit when the issue is resolved.

The distinction between Refs and Fixes matters: Refs #42 links the commit to the issue without closing it; Fixes #42 triggers auto-close on merge. Using Refs on intermediate commits lets the issue stay open as a tracker while work is in progress.

Closing the issue from the Aider session

Once the commit is made, closing the issue is one gh call away. Aider can run shell commands, so you can ask it directly:

Close issue #42 on GitHub with a comment linking to the commit.

Aider will run something like:

gh issue close 42 --comment "Fixed in $(git rev-parse --short HEAD). Closes #42."

This leaves a paper trail on the issue itself: anyone who lands on it later sees both the resolution comment and the commit reference. Cleaner than just letting the issue auto-close from the commit message with no explanation.

If you’d rather handle the close yourself, git push followed by gh issue close 42 achieves the same result in two steps. The auto-close from Fixes #42 in the commit message only triggers after the branch merges to the default branch, so for work done directly on main, the push is enough.

Issues that are a bad fit

The workflow breaks down predictably on two issue types.

Vague issues. “Make the search faster” is not a task; it’s a category. Aider will ask clarifying questions, or worse, pick a plausible approach and run with it. The resulting plan is often off-target because the issue doesn’t constrain the solution space. Before pulling a vague issue into Aider, add acceptance criteria to it — or write your own in the Aider prompt:

The goal is to reduce the search response time from ~800ms to under 200ms
for queries against the product table with more than 10k rows. Focus on
the query in src/lib/search.ts.

With that framing, the session has a target. Without it, “faster” could mean anything.

Multi-system issues. “Rewrite the auth system to use JWTs” spans multiple files, touches security boundaries, probably requires a migration, and will interact with every downstream part of the app that reads session state. These issues look like one task but are actually five or ten tasks that need to be sequenced and reviewed individually.

The tell: if reading the issue makes you think “we should probably discuss this before touching code,” Aider will have the same problem. Break the issue into sub-issues with narrower scope — “Add JWT generation on login” and “Migrate session reads to validate JWTs” are separable, reviewable, and safe to feed to Aider one at a time.

The rough heuristic: an issue that a single developer could reasonably close in under two hours is Aider-ready. Anything larger benefits from decomposition first.

A third category worth naming: issues with unresolved disagreement in the comments. If the last three comments are maintainers debating which of two approaches is correct, Aider will pick one — likely the one that appears most recently or most often — without flagging that there was a disagreement. Before feeding that issue in, resolve the debate and add a comment with the decision. The model is good at executing decisions; it’s unreliable at making them on your behalf from contested threads.

The earned insight

The improvement from this workflow over copy-paste isn’t speed. It’s fidelity. Comment threads carry decisions that didn’t make it into the issue body — workarounds that were rejected, approaches that were tried and failed, constraints that were added after the original report. Aider reading the thread means the plan it proposes reflects what the team actually decided, not just what was written at 9am before the discussion happened.

There’s also a side effect worth noticing: the act of reviewing Aider’s proposed plan against the issue thread is itself useful. If the plan misses something obvious from the comments, that’s a signal the issue is under-specified, not that Aider is broken. Fix the issue, not the model.

That said, a well-written issue with a clean description and no comment noise is easier for Aider to work with than a 40-comment thread where the scope shifted three times. The workflow pulls whatever’s in the thread. If the thread is unclear, the plan will be too. Triage the issue before feeding it. The cleaner the issue, the less you need to supervise the execution.