What access does a GitHub credential need for Tares to read a repository’s issues as tickets?

Tares reads a repository’s issues as tickets with any GitHub credential that can read that repo’s issues. Add it in Settings > GitHub: a fine-grained token needs the repo with Issues: read, a classic token needs the repo scope, and a GitHub App needs the Issues permission and an installation on the repo. Tares tries your stored credentials one after another until one can read the repo, so an existing GitHub connector credential works.

How it works

The GitHub Issues connector is a poll connector. Tares reads the linked repo about once a minute, and Sync now on the project’s Tickets page reads at once. It only reads from GitHub. Sessions create and change issues in GitHub themselves.

Credential access works like this:

• Fine-grained token: it needs access to the repo with Issues: read.
• Classic token: it needs the repo scope.
• GitHub App: it needs the Issues permission and must be installed on the repo. An App with no installation is skipped, so a permission on its own is not enough.
• Several credentials: Tares goes through the stored credentials one after another and uses the first one that can read the repo. You do not pick which one a project uses.

Because of that fallback, a credential you already added for the GitHub connector can serve the issues too, as long as it meets one of the rules above.

This is one of the ways a project in an AI SRE setup can keep its tickets outside Tares. Each issue that carries the project’s issue label becomes a ticket, and every change in GitHub becomes an event that triggers and agents can react to.

Set it up

1. Open Settings > GitHub and add a credential that meets the access rules above. If you already have a GitHub connector credential that can read the repo’s issues, you can skip this step.
2. Open the project’s Tickets page and click Use GitHub Issues.
3. Pick or type the repo as owner/name, check the issue label, and click Link. The label is optional and defaults to tares: followed by the project name.
4. Or ask a connected agent to call the MCP tool link_github_issues:

link_github_issues(repo="acme/shop", issue_label="tares:shop")

5. Let sessions create the issues. The sessions that create issues use gh with the repo scope. When you plan a project with /tares:spec and say the tickets should live in GitHub Issues, Claude creates them with gh and links the project.
6. Verify. The Tickets page shows “Tickets live in GitHub” with the repo, the issue label and the time of the last sync. Close an issue in GitHub and, within a minute, the ticket moves to done. The source’s Recent events shows the change.

Tares creates the github_issues source the first time a project is linked. A repo and issue label belong to one project. A project that already has tickets of its own, or keeps them in Linear, cannot be linked.

What you get

• Every issue that carries the issue label becomes a ticket named GH-12 for issue 12, with its title and status, in issue number order.
• Status follows the issue: open is todo, open with the in progress label is in_progress, closed as completed is done, and closed as not planned or as a duplicate is canceled.
• GitHub milestones that the labeled issues belong to show up as milestones, and an issue that is blocked by another makes its ticket depend on that one.
• One event per change on the github_issues source: ticket_created, ticket_renamed, ticket_status and ticket_removed. The provided labels are ticket, project and repo.
• A safe failure mode. If a credential is revoked, loses sight of the repo, or GitHub is unreachable, the Tickets page shows why, the tickets stay as they were and nothing is canceled. Fix the cause and the next sync picks up.
• If GitHub rate limits the sync, Tares waits five minutes before it tries again.

The tickets are read-only in Tares. To change a title, status, milestone or dependency, change the issue in GitHub. Working docs stay yours to write in Tares.

When something else fits

• If your project already has tickets of its own or keeps them in Linear, it cannot be linked to GitHub Issues. Stay with the tickets you have.
• GitHub Issues covers one repo and one issue label per project, github.com only, with no GitHub Projects boards and up to 1000 labeled issues. Group tickets with GitHub milestones, and use another ticket home if you need more than that.
• To stop using GitHub for tickets, click Stop using GitHub on the Tickets page. The tickets and milestones return to Tares with their working docs, and the issues in GitHub stay as they are.

Related