BlogTasks and GitHub Issues
How do I connect Claude Code to GitHub Issues?
The simplest way is the GitHub CLI. Once gh is installed and logged in, Claude Code can read issues, comment on them and open pull requests through it, with nothing else to configure. You can also add GitHub's remote MCP server with claude mcp add, or install Claude Code GitHub Actions with /install-github-app so that mentioning @claude in an issue starts a run on GitHub.
Here is how each option works, as documented in October 2026, and when to pick which.
Option 1: the gh CLI (local, no setup in Claude Code)
Anthropic's best-practices guide recommends CLI tools for external services because they are the most context-efficient option, and says Claude knows how to use gh for creating issues, opening pull requests and reading comments.
brew install gh
gh auth login
Then, inside Claude Code, refer to issues by number:
Read issue 123 with gh issue view, find the cause, fix it, and run the tests.
The commands Claude will use are standard gh:
gh issue list --label bug --state open # find work
gh issue view 123 --comments # read the issue and its thread
gh issue view 123 --json title,body,labels # structured output for scripts
Make it repeatable with a skill
Anthropic's best-practices guide shows a skill for exactly this. A shortened version, saved as .claude/skills/fix-issue/SKILL.md:
---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.
1. Use `gh issue view` to get the issue details
2. Search the codebase for relevant files
3. Implement the change and write tests
4. Run tests, linting and type checking
5. Commit, push and create a PR
Run it with /fix-issue 123. disable-model-invocation: true means Claude never starts it on its own, which is what you want for a workflow that pushes code.
Option 2: GitHub's remote MCP server
If you prefer tools over shell commands, Claude Code's MCP docs show how to add GitHub's server. It authenticates with a fine-grained personal access token:
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
--header "Authorization: Bearer YOUR_GITHUB_PAT"
claude mcp add saves the config without checking the token. Run /mcp inside Claude Code and check that the server shows a checkmark. Then ask in plain language:
Show me all open issues labeled bug, then pick the oldest one.
The default scope is local (this project only). Add --scope user to load it in every project.
Option 3: Claude Code GitHub Actions (runs on GitHub)
This one is different. Claude Code runs in your repository's workflows, not on your machine. Open claude in the repository and run:
/install-github-app
It installs the Claude GitHub App, sets up an authentication secret and prepares a pull request with the workflow file. Merge it, and @claude works in the repository. It only supports github.com repositories.
In interactive mode (no prompt input in the workflow), Claude waits for @claude in an issue comment, a pull request comment or review, or the title or body of a newly opened issue. It responds with progress and results as a comment on that issue or PR:
@claude implement this feature based on the issue description
By default, the person who triggers the run must have write access to the repository. You can allow specific users without write access with allowed_non_write_users.
Which one to choose
| You want | Use |
|---|---|
| To work on issues from your own terminal, with your own review | gh |
| Structured tool calls instead of shell commands | GitHub MCP server |
| Issues turned into PRs without opening a terminal | GitHub Actions |
Most people who run agents locally end up with gh: it works in any session, needs no token in Claude Code's config, and it is what Claude already knows.
Limits of these methods
- No overview. Neither
ghnor MCP shows you which issue is being handled by which terminal. You keep that mapping in your head. - Copy and paste. You still type or paste issue numbers into each session. Giving Claude Code a task from an issue without copy-pasting covers a one-line launcher.
- Untrusted text. An issue body is written by whoever opened it, and Claude reads it as part of its prompt. Anthropic documents prompt injection as a risk, with the permission system as a core protection. Read issues from outside contributors before you hand them to an agent that can run commands.
- Reporting back is up to you or the prompt. See how to put what Claude Code did back on the issue.
With Kanbell
Kanbell is a macOS app with one window per project and real terminals in panes and tabs. Its task board can be local or backed by GitHub Issues, with columns either open/closed or by labels.
- Launch from a card. Pick an issue and launch an agent: the brief is pasted into the terminal, not sent. You read it and press Enter.
- Outside authors. If the issue was opened by someone outside the repository, Kanbell asks for confirmation before launching.
- Agents read the board. The
kanbellCLI lets agents list and show cards (kanbell list,kanbell show). On GitHub, the CLI is read-only: agents write with their owngh. - Summary back on the issue. For Claude Code, Kanbell publishes the session summary as a comment on the issue.
Kanbell supports local boards and GitHub Issues only. There is no Linear, Jira or Trello integration.
FAQ
Do I need an MCP server to work with GitHub issues?
No. Anthropic's best-practices guide recommends CLI tools like gh as the most context-efficient way to reach external services, and says Claude knows how to use gh for issues, pull requests and comments.
Can anyone trigger @claude on my repository?
By default, on issue and pull request events the triggering user must have write access to the repository. You can allow specific users with allowed_non_write_users.
Does /install-github-app work with GitLab?
No. It works only with github.com repositories. Anthropic documents a separate GitLab CI/CD integration.
Where does Claude's answer appear when I mention @claude in an issue?
In interactive mode, progress and results appear as a comment on the issue or pull request that triggered the run.