What it can actually do to your code

You are being asked to let a set of agents write to a repository you care about. That deserves a straight answer rather than reassurance, so this page is the boundaries: what it needs from you, where it runs, what it changes, what stops it, and what it can still get wrong.

Everything here is checkable. The engine is open source under AGPL-3.0, and the claims below are things you can read in it rather than take from us.

It runs on your machine, on your credential

There is no hosted service here and no account to create. The team is Claude Code sessions running on your hardware, authenticating as you. It needs a Claude credential you already own, an authenticated gh CLI, and Node and Python on the path. Nothing here provisions any of those, and nothing bills you — your model spend goes to your own subscription or API key, which is the subject of the cost page.

The practical consequence is worth stating plainly: the agents act with your GitHub permissions. They are not a third party you are granting access to. They are a program on your machine using the token you gave it, and the ceiling on what they can reach is the ceiling on what that token can reach. Scoping it is the highest-leverage thing you can do before a first run.

Work happens in isolated worktrees, never on main

Each agent role works in its own git worktree, sandboxed from the main branch until its pull request has been reviewed and merged. Runtime state — the blackboard, session data, metrics, the audit trail — lives outside the repo entirely, so a worktree merge cannot wipe it and a bad change cannot corrupt the record of what happened.

What lands in a target repo depends on the route you took. /coldstart populates it: CLAUDE.md, the agent role definitions, the commands, backend/, scripts/ and hooks/, plus a .autonomous-team/ directory holding state and project config and the merge-gate labels. Running scripts/coldstart.sh from a clone without that population step leaves only .autonomous-team/ and the labels, with everything else staying in the engine checkout. Either way the runtime state lives outside the repo, and the dashboard’s own code is never installed into it.

Four gates stand between a change and your main branch

Every change starts as a Discussion and ends as a merged pull request, and the loop will not merge one until the gates it needs are present. These are labels applied by the merge machinery rather than prose, which is what makes them facts rather than readings:

A code-reviewer agent reads the diff against the Spec. A security-reviewer checks it for auth, injection, secret-handling and sandbox-rule risk. An acceptance-tester runs the actual build and tests against the Spec’s criteria. A browser-tester verifies UI changes in a real browser. Not every change is asked for every gate — a docs edit is not put through a browser test — and the mix across every merged pull request is counted on the ship page.

One real pull request, start to finish is the best way to see what that costs a change in practice — the rejections, the re-reviews, and how many rounds it took to answer them.

Autonomy is a dial, and it does not turn itself up

How much the team may do unattended — spawning agents, merging, writing to GitHub, archiving — is governed by a set of dials, each on its own 1-to-5 scale, where 1 is most restricted. They are independent: you can allow it to open pull requests freely while refusing it the ability to merge one.

The part that matters for trust is how a dial moves. Every mutation path requires an allowlist entry that already exists — the caller passes a source descriptor, and if that descriptor is not already listed, the change is refused. It is not a confirmation prompt an agent can talk its way through; it is a file that has to have been edited out of band first. And some classes carry a hard ceiling that no directive can raise at all: the dial governing modification of the sandbox rules themselves ships with a ceiling of 1, meaning it can never be turned up.

What it still gets wrong

This is an experimental project, not a finished product, and the gates above are agents too — they are better than no review and worse than a careful human. The honest version of their failure mode is the one this project writes about constantly: not code that fails, but code that passes and is wrong. A check that reports success because it failed to look is the defect underneath most of what the blog documents, and several of those were in the checking machinery itself.

So: keep branch protection on. Keep the token scoped. Read the pull requests — they are designed to be readable, and every one of ours is public. Treat the team as something that does the routine implementation loop well and needs you to stay the one deciding what is worth building.

Found something?

Security-relevant or not, report it. There is a sandbox-and-permissions category on the form specifically for this, and it reaches a human.