Give your coding agent a list of issues and get pull requests back. fleet runs each issue in its own sandbox with its own agent, all at once, and asks you only when a decision is yours.
You only talk to one agent, the host, on your Mac. It starts a sandbox per issue, keeps an eye on all of them and checks the finished work before anything lands. Questions it can't answer come to you. Every command any agent runs passes a tested guard first.
You talk to one agent on your Mac, the host. Say it in plain words, give it Linear issues, or hand it a markdown file.
|
Each sandbox is a private copy of the repo with its own agent. Sandboxes run side by side and can't touch each other or your checkout.
|
The agents answer whatever the code or the tracker can answer. Everything else reaches you as one short question.
|
Each one is tested and reviewed, and tried in the running app when it changes what users see. It lands when you say so, and the repository's profile decides who opens the pull request.
|
You need a Mac with Apple Silicon and zsh, Docker Sandboxes, Herdr app, Node, Claude Code and pi, and a Claude plan and a model provider for pi (setup step 1 matches the models to what you have).
git clone https://github.com/jaqubowsky/fleet ~/fleet
cd ~/fleet && claudeThen tell your agent: "read SETUP.md and set me up". It checks what you have, asks what it can't know, and ends by starting and stopping one test sandbox.
After setup you work from Herdr app in its fleet layout: open a tab in your repository and run plain claude or pi. The host only wakes for the sandboxes its own session started or steered.
Rather do it by hand? Follow the same steps yourself: SETUP.md lists them, one file each.
Every sandbox agent follows the same run. It works out the task, cuts it into small tickets and builds each one test first, committing only after the checks pass.
Then a second agent reviews the change whenever it reaches beyond its own feature. It never saw the implementation, so it reads the diff the way a stranger would, for bugs and for code quality. When the change is something users see, the sandbox opens the running app in a real browser and takes one screenshot per acceptance criterion. It records a video walkthrough when you ask for one.
Once the pull request is open, tell the sandbox to babysit it. It answers review comments and fixes red checks, round after round.
The host sleeps until a sandbox needs something, then wakes up with what changed.
Every tool call an agent makes goes through a policy first. This is what an agent gets back when it tries to rewrite history:
| Stopped | Example |
|---|---|
| Rewriting shared history | git push --force, delete and mirror pushes |
| Reading secrets | SSH keys, the keychain, op read, gh auth token |
| Changing its own rules | writes to ~/.claude and ~/.pi |
| Deleting your work | rm -rf on home and project folders |
| Acting on GitHub for you | merging a PR in another repository |
The host agent runs these for you. Each one is listed with what it changes, so nothing happens that you can't look up.
| Command | What it does | What it changes |
|---|---|---|
./sync.sh |
shows what --apply would change for each agent whose CLI is on PATH, and names the backup archive it would write |
nothing |
./sync.sh --apply |
installs the harness for each agent whose CLI is on PATH and builds its sandbox image |
first packs every file it will change into ~/.fleet/backups/<UTC timestamp>.tar.gz; replaces ~/.claude/{rules,refs,skills,agents} and ~/.pi/{skills,agent/refs,agent/agents,agent/themes} of the agents it sets up; writes keys into ~/.claude/settings.json and links the guard hook into ~/.claude/hooks with claude; links fleet and a gh wrapper into ~/.local/bin, and the fleet layout and its mods into ~/.config/herdr-app |
fleet up <label> --repo <path> |
starts a sandbox for a task, its agent waiting in a Herdr app tab | creates a sandbox with a private clone and your repository's ignored .env files; stores the profile's GitHub token as an sbx secret; adds a task folder under ~/.fleet/tasks/ |
fleet stop <sandbox> |
stops the sandbox, keeping its files | ends guest processes and closes its tab; fleet ls and the watch show stopped |
fleet start <sandbox> |
opens a new tab with the last saved session when one exists | starts the sandbox and agent; sends no prompt |
fleet steer <sandbox> "<text>" |
sends the sandbox agent its next instruction | nothing outside the sandbox |
fleet watch |
wakes the host when a sandbox settles, with its closing message | nothing |
fleet ls, fleet peek <sandbox> |
list the sandboxes, show what one is doing | nothing |
fleet patch <sandbox> |
print the sandbox's changes as one patch; the Changes panel reads it | nothing |
fleet artifacts |
list task folders | nothing |
fleet exec <sandbox> -- <command> |
runs a command inside a sandbox | whatever that command changes there |
fleet copy <src> <dst> |
copies a file in or out of a sandbox | the destination file |
fleet land <sandbox> [--push] |
brings the finished branch home | moves your local branch; signs commits per profile, which changes their SHAs; --push pushes to GitHub |
fleet down <sandbox> [--force] |
closes the sandbox, keeping its task folder | removes the sandbox; refuses unlanded work, which --force throws away |
fleet profile [<repo>] [--apply] |
shows who may push, open and merge pull requests, per repository | with --apply: the checkout's git config (signing, HTTPS origin, credential helper) and its Linear MCP registration. Every host session start runs this on its own checkout |
fleet tokens [set <name>] |
lists the GitHub tokens the profiles name and marks the ones missing from the macOS keychain; set asks for one and stores it |
with set: one keychain item under fleet-gh. Run it yourself; the guard refuses it to agents |
fleet build [--pi|--claude] |
rebuilds a sandbox image | the local sbx image |
fleet init <repo> |
lays out AGENTS.md and spec/vision.md |
adds those files to the repository, never overwriting one |
fleet render |
renders one seat's files | the seat's home, or --out <dir> |
fleet --help lists every flag.
In the fleet layout, the Agents pane shows a PR #n pill in a container's row once its agent opened a pull request, and a click opens it on GitHub. Stopped containers stay listed there under Stopped. The tab bar's Changes button turns that tab's work area into what the container changed, read-only, the way GitHub's Files changed view does: a file tree with a filter, and each file as a card with its coloured diff. It stays on that tab only. In any other tab it shows the local checkout's changes. Changes compare the working tree to the merge base of HEAD and the container's origin base branch, so rebasing does not include unrelated upstream changes. No fetch runs while viewing. A task with several repositories shows them in one tree, each path under its repository's name. New untracked files are included; ignored files are excluded. A stopped container is not read and not started. Files larger than 4 MiB show only their name, and a diff over 400 lines waits for a click.
Use fleet stop to release a sandbox's resources without deleting its work. fleet start restores the saved conversation in a new tab, not an interrupted tool call or app server. fleet ls, fleet peek and the watch leave stopped sandboxes asleep; steer and exec require a start first. Raw sbx exec starts a stopped sandbox, even for a read.
- Several repositories in one task. Repeat
--repo, and onelandbrings all of them home. - Permissions per repository.
fleet profileshows who may push, open and merge pull requests, for the host and for the sandbox. - Cost per task.
fleet lsshows what each sandbox has spent so far. - A record of every task. Plan, review and logs stay in a task folder after the sandbox is gone.
- Session retrospectives.
audit-harnessreads a selected session, defaults to the current one, and proposes the smallest environment changes for observed friction and mistakes. Each proposal includes evidence and cost; nothing is edited. - Your phone as a remote. Drive pi sessions from your phone over Tailscale, set up as extensions/pi-remote describes.
Sandboxes never hold your SSH or signing key, and their GitHub token reaches them only through the sandbox proxy. The host agent on your Mac gets a repository's token from the keychain only for the gh command that needs it. A repository's ignored .env files are copied into its sandbox. Three things never happen without you:
- a force, delete or mirror push, from any seat;
- a pull request opened or merged where the repository's profile doesn't give the host
auto, since the guard refuses it; - a push or a signature with your key, since the key waits for your Touch ID on the Mac.
The guard matches patterns and doesn't understand the shell, so eval gets past it. A repository's own .claude/settings.json can also switch off user hooks. It stops mistakes. Someone who has read the rules can get around it.
Rules, skills and the guard are written once in this repo and rendered for both Claude Code and pi. To add a skill, drop a SKILL.md into skills/shared, skills/host or skills/container and run sync. It reaches each agent sync sets up, on your Mac, in the sandboxes or both. Edit or delete the bundled skills the same way. Keep them in the repo, because sync replaces ~/.claude/skills on every run.
It is opinionated and built around how I work. Fork it and let your agent bend it to yours.
MIT. The software comes as is, without warranty of any kind, and the authors are not liable for anything it does.
fleet runs AI agents that execute commands on your Mac and in sandboxes, with your GitHub tokens and, where a repository's profile allows, your permission to push and merge. The guard stops known mistakes, not every one (see the trust model above). Read fleet profile for each repository before its first task, scope every token to what that repository needs, and keep your own backups.
Third-party code and its licenses: THIRD_PARTY_NOTICES.md.