How to run AI coding agents against a real repository safely

Trying a coding agent on a toy repository is easy. Pointing a team of them at a repository you care about is a different question, and it deserves a list of boundaries rather than reassurance: what the agents can reach, where they do their work, what they are allowed to change, and what stops them.

Five questions to answer first

Whose credentials do they use? An agent that acts on GitHub acts with some token’s permissions. Whatever that token can reach is the real ceiling, whatever the documentation says.

Where does the work happen? Changes should be made somewhere other than your main branch, and reach it only through review.

Where does their state live? If the record of what the agents did lives inside the repository they are editing, a bad change can rewrite the evidence of itself.

What must be true before a merge? A merge step that refuses without independent checks, over the top of your own branch protection.

Who can widen what they are allowed to do? If an agent can turn its own permissions up, the permissions are a suggestion.

It runs on your machine, with your credential

FULCRUMAXE has no hosted service and no account to create. The team is Claude Code sessions running on your hardware, authenticating as you. It needs Claude Code on your path, a Claude credential of your own — a subscription or an API key — an authenticated gh CLI, and Node and Python. Linux with GNU coreutils is the supported environment. (Getting it running.)

The consequence the safety page states plainly: the agents act with your GitHub permissions. They are not a third party you grant access to; they are a program on your machine using the token you gave it. Scoping that token is the highest-leverage thing you can do before a first run.

Work stays off main, and state stays out of the repo

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 repository entirely, so a worktree merge cannot wipe it and a bad change cannot corrupt the record of what happened.

What lands in a target repository depends on the route. /coldstart populates it — CLAUDE.md, the agent role definitions, the commands, backend/, scripts/ and hooks/, plus .autonomous-team/ and the merge-gate labels. Running scripts/coldstart.sh from a clone without that step leaves only .autonomous-team/ and the labels. Either way runtime state stays outside the repository.

Read the plan before it touches anything

From a clone, bash scripts/coldstart.sh --path … --dry-run prints the ordered plan and writes nothing: no files, no state directory, no GitHub API calls. You can also run the same plan in your browser, answer the real setup interview, and read the two files it would generate.

A real run installs the merge-gate labels, the sandbox hook, a state directory and dependencies — and then halts and exits zero without seeding any work. The next step is deciding what the team should work on, and that is left to you on purpose.

Four gates before main

The loop will not merge a change until the gates it needs are present: code-review-passed, security-review-passed, acceptance-passed and browser-test-passed, labels applied by the merge machinery rather than prose. What each checks, and where gates like these still fail, is in the merge gates guide.

Limits it cannot raise on its own

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

Changing a dial requires an allowlist entry that already exists. 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. Some dials also carry a hard ceiling that nothing raises: the one governing changes to the sandbox rules themselves ships with a ceiling of 1.

You can watch a ceiling hold on the try page: ask the setup interview for external.system at level 5 and the generated file says 2, because that is the ceiling and there is no override flag.

What it still gets wrong

This is an experimental project, not a finished product, and the gates are agents too — better than no review, worse than a careful human. The failure to plan for is not code that fails but code that passes and is wrong, including in the checking machinery itself; the blog documents several.

So the advice does not change with the tooling: keep branch protection on, keep the token scoped, read the pull requests — every one of this project’s own is public — and stay the one deciding what is worth building. If you find something, the bug form has a sandbox-and-permissions category that reaches a human.