Repo Fleet documentation

Repo Fleet is where you build AI agents for your GitHub repositories and run them on your own runners with your own model key. What that means, what it is not, and how to start.

An AI coding agent is a model wrapped in a loop and handed tools: it reads files, edits them, runs commands, and keeps going until the work is done. What separates it from a model and from a control plane, what a run actually does, where it runs, what it costs, and what to decide first.

Install the Repo Fleet GitHub App on an account and pick the repositories it may see.

Write the starter workflow into a repository, give it a key and a label, and watch the first run.

Edit one workflow file on the Visual or Code tab, with every keystroke checked before you save.

Start from a workflow that already runs, and swap one in without committing anything.

What a run is handed, what it hands on, and where a model key lives.

What the Runs page lists, the window it reads, and where every printed line lives.

Where an edit lands, where an agent's own work goes, and why a schedule ignores your branch.

What a run spends and on whose account, the four caps that bound one run, where a run reports its own cost, what each plan reaches, and the handful of things that go wrong first.

The complete workflow that runs Claude Code on a labelled issue and opens a pull request, with the API key kept secret, the token permissions it needs, what a run costs, and how to cap it.

Claude Code headless on a cron in GitHub Actions: the schedule trigger, the label queue one run takes one issue from, the concurrency group, the turn and budget caps, and what to read the next morning.

The complete workflow that reviews every pull request with Claude Code: the pull_request trigger, a read-only checkout, the one permission the comment needs, what the review says, and what a review costs.

Both agents run as one step in a workflow you own, on your runner and your key. The two workflow files side by side, what each action does for you, and how to pick.

One ships a GitHub Actions step, the other a CLI you install in a run step and a cloud agent on its own machines. What each does unattended, the workflow file, and how to pick.

One action takes any trigger you name; the other answers a comment and refuses every other event. The headless command for each, the workflow file for each, and how to pick.

Claude Code hooks in GitHub Actions: what PreToolUse blocks, how exit code 2 works, where .claude/settings.json lives in the repository, what a blocked action prints in the run log, and what a hook cannot stop.

Several Claude Code agents in one GitHub Actions workflow: the strategy.matrix that fans one job out into many, a brief and a budget for each, needs to make a reviewer wait for them, and how that differs from subagents.

Two systems bound a Claude Code run in GitHub Actions: the workflow permissions block that scopes the token GitHub mints, and allowedTools, which decides what the agent may call. Neither one constrains the other, and an unattended run has to set both.

A workflow holds jobs, a job holds steps, and a step does one thing. What each is, where it lives, what env and defaults set around them, what the editor calls each one, and what gets you in trouble.

What starts a workflow and how to say when. Triggers, activity types, filters, cron, and manual runs, then one table of every event GitHub fires, what fires by default, and what narrows it.

The machine a job gets and the shell a command lands in. Hosted labels and what a minute of each costs, hosted against self-hosted, runner groups, the shell defaults, and the folder a command starts in.

Using somebody else's step, and choosing which version of it you trust. The three shapes of uses, the inputs an action declares under with, and what a tag, a branch, or a commit each costs you.

The curly braces, where their values come from, and how to make a job or a step run only sometimes. Every context and function in a table, the usual conditions as recipes, and the rules that catch everybody once.

The token every run carries, the scopes it gets, and where the other credentials live. Every scope in a table, the three levels and what unset means, and the rules that turn a workflow into somebody else's key to your repository.

Jobs all start at once until you say otherwise. needs puts them in a line, a matrix turns one job into many, and outputs carry a value between them. The run count worked out, the quoting trap, and what a wide matrix really costs.

The three keys that stop a workflow burning your money, queueing over itself, or falling over on something that does not matter. The six-hour default, three concurrency recipes, and what letting a failure slide really hides.

Write a workflow once and call it from everywhere. What workflow_call declares, what a calling job may and may not have, what inherit really hands over, and how an environment makes a deploy wait for a human.