What happens to a ticket in GitHub Issues when its pull request merges?

Tares reads the ticket from the GitHub issue and never writes to GitHub, so what you see on the ticket follows what the session did to the issue. Sessions update the issue with their own tools, and about a minute later Tares reads the change. An issue closed as completed moves its ticket to done, and the project page shows the ticket with its pull request and merge state.

How it works

When a project keeps its tickets in GitHub Issues, one repo and one issue label pick the issues. Those issues become the project’s tickets, named GH-12 and so on. Tares only reads from GitHub. Sessions create and change the issues in GitHub itself, with gh.

That split decides what happens around a merge:

• Sessions write. The builder and the other sessions of the software factory for Claude Code update the issue with their own tools. Tares does not close, label or edit the issue for them.
• Tares reads. Tares reads the repo about once a minute. Sync now on the Tickets page reads at once.
• Status follows the issue. The ticket status comes from the issue:

• Every change is an event. A move to a status that maps to a different Tares status becomes a ticket_status event on the github_issues source, keyed by the ticket name. A renamed title is a ticket_renamed event. Triggers and agents can react to these events like any other event.

The tickets are read-only in Tares. To change a title, status, milestone or dependency, change the issue in GitHub.

On the project page, the Tickets fold lists each ticket with the builder that held it, its pull request and its review rounds. A ticket shows one of these states: to do, in progress, in review, merged or blocked. The GitHub fold lists the repos the project changes, with their open and merged pull requests. For Tares to read pull request, CI and merge state, it needs a GitHub token. The crew asks you for one if it is missing. A project, end to end walks through a project with eight merged pull requests.

Set it up

1. Add a GitHub credential in Settings > GitHub. A fine-grained token needs the repo with Issues: read. A classic token needs the repo scope. A GitHub App needs the Issues permission and must be installed on the repo.
2. Link the project. On the project’s Tickets page, click Use GitHub Issues, pick or type the repo (owner/name), check the issue label and click Link. Or ask a connected agent to call the MCP tool:

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

The issue label is optional and defaults to tares: followed by the project name. Tares creates the github_issues source the first time you link a project. 3. Sign in with gh so the sessions can create and update the issues. They need the repo scope:

gh auth login

4. Plan the project with /tares:spec and say the tickets should live in GitHub Issues. Claude then creates them with gh and links the project. See Get started for the full factory setup.
5. Check the link. The Tickets page shows “Tickets live in GitHub” with the repo and issue label, and when it last synced. Close an issue in GitHub, and within a minute the ticket moves to done. The source’s Recent events shows the change. Read more on the GitHub Issues connector page.

A project that already has tickets of its own, or keeps them in Linear, cannot be linked. A repo and issue label belong to one project.

What you get

• One place to look. The ticket, its pull request and its merge state sit together in the project’s Tickets fold, and the pull requests sit in the GitHub fold.
• Status that follows the issue. When a session closes the issue as completed, the ticket shows done after the next read. If the issue is closed as not planned or as a duplicate, the ticket shows canceled.
• Events to react to. Each status change is a ticket_status event with from and to values, the issue and the repo in its payload, so triggers and agents can act on it.
• A safe read. If a sync fails, the tickets stay as they were and nothing is canceled. An issue that loses its label becomes canceled instead of disappearing, so its working doc stays reachable.
• Your own working docs. The working doc of each ticket stays yours. You write it in Tares even though the ticket itself is read-only.

When something else fits

• If you want to edit tickets, milestones or dependencies inside Tares, keep the tickets in Tares. Use Stop using GitHub on the Tickets page to bring them back. The issues in GitHub stay as they are.
• If your team tracks work in Linear, link a Linear project instead. It works the same way: sessions write, Tares reads.
• GitHub Issues linking covers github.com only, with one repo and one issue label per project and up to 1000 labeled issues. GitHub Enterprise Server and GitHub Projects boards are not supported, so group tickets with GitHub milestones.

Related