Why does Tares need its own GitHub access when the builders already push with my gh login?

Tares needs its own GitHub access because builders push and open pull requests with your gh login, while Tares reads the pull request, CI and merge state of every ticket itself. On Tares Cloud you choose Connect GitHub in your workspace settings and pick the repos. On a local Tares you add a GitHub token or App under Settings > GitHub. Once both are in place, the crew carries each ticket from branch to merged pull request and Tares keeps the record.

How it works

Two different jobs use GitHub in the software factory for Claude Code, and each has its own access.

• Builders use your gh login. Each builder takes a ticket, works on its own branch, opens a pull request, and merges it once the reviewer passes it and CI is green. That work runs as Claude Code sessions on your machine, so it uses the gh login you set up, which needs write access to the repos the crew works in.
• Tares uses its own access. Tares is the crew’s backbone. It holds the plan, the tickets and their stages, every review, the assumptions the crew made and your answers. To keep each ticket’s stage correct, Tares reads the pull request, CI and merge state of that ticket itself, so it needs its own access to the repos.

The reviewer posts its verdict on the pull request, and the builder merges after that verdict and green CI. Tares tracks that progress and shows it on the Crew page, with each open project, its builders and the pull requests waiting for review.

The sessions come and go, but the record stays on Tares. A crew that restarts carries on where it stopped. For the full walkthrough, see Get started.

Set it up

1. Check that Claude Code is signed in, that gh is signed in with write access to the repos the crew works in, and that git, jq and curl are installed.
2. Install the CLI with uv tool install tares (or brew install glassflow/tap/tares).
3. Point the crew at Tares:
   • Local Tares: run tares up, then in a second terminal start the MCP endpoint every crew session shares with tares mcp --transport streamable-http.
   • Tares Cloud: run tares login and pick your workspace in the browser.
4. Give Tares access to GitHub:
   • Tares Cloud: in your workspace settings, choose Connect GitHub and pick the repos.
   • Local Tares: add a GitHub token or App under Settings > GitHub.
5. Bring up the crew, then check that everything it needs is in place:

gh auth login
tares factory crew up
tares factory doctor

6. Plan a project with tares factory spec "what you want to build". The orchestrator picks it up once you hand it over.

If a project’s tickets live in GitHub Issues, add a GitHub credential in Settings > GitHub that can read the repo’s issues. Also sign in to gh with the repo scope on the machine that runs the sessions:

gh auth login --scopes repo

Sessions create and change the issues with gh. Tares reads them about once a minute to keep the project’s ticket list in step, and it never writes to GitHub.

What you get

• Builders push and open pull requests as you, with the gh login you already have.
• Tares reads the pull request, CI and merge state of every ticket on its own, so ticket stages follow what happens on GitHub.
• The Crew page shows each project’s progress, its builders and the pull requests waiting for review.
• Every review, assumption, question and answer stays on Tares, so a restarted crew carries on where it stopped.
• tares factory doctor checks everything the crew needs, so you can confirm the setup at any point.
• With GitHub Issues as the ticket source, the project’s ticket list stays in step with the repo without Tares writing to it.

When something else fits

• If you keep a project’s tickets in Linear, connect Linear in Settings > Linear and use Use a Linear project on the project’s Tickets page. Tares only reads those tickets.
• If you want to work on one project in your own Claude Code session rather than with a crew, use tares factory session.

Related