A local Git remote turns agent review into a repeatable gate
No Mistakes creates a local remote named no-mistakes. Push a branch there and the tool copies the work into a disposable worktree, then reviews it, runs repository checks, updates documentation, lints, pushes, opens a pull request, and watches CI. The real remote receives the branch only after the configured steps are green. That is easier to repeat than asking an agent to remember an improvised checklist after every coding task.
The same pipeline has 3 entry points: a Git push, the terminal interface, or an installed /no-mistakes skill. The skill matters for Claude Code, Codex, OpenCode, Cursor, and the other agents named in the README because it gives them a structured approval protocol. Mechanical changes can be fixed, while decisions about intent are supposed to stop for a person to approve, repair, or skip.
A 32-second install still needs agent and GitHub credentials
The published installation can be one shell command, followed by no-mistakes init. That initialization records the actual push target, creates the gate, and installs its coding-agent skill. Source development uses Go and exposes Make targets for builds, race-enabled tests, linting, generated skills, documentation, and an end-to-end suite.
Useful operation needs more than the binary. Every gate requires a runnable agent with authentication and quota. Pull-request creation and CI watching need GitHub access, while each repository must supply dependable test, lint, and formatting behavior. The README warns that re-recording end-to-end fixtures calls real agent CLIs and spends real API quota. Teams should set their own time and cost ceilings before allowing unattended repair rounds.
What happened when we ran it
Our sandbox installed 67 Go packages in 32 seconds, then built commit c2a75d0 successfully in 41 seconds. The checkout contained 744 files, about 202,065 source lines, and occupied 9 MB before installation. That is a modest checkout, though the complete test command took far longer than install and build together.
Tests ended with exit code 1 after 783 seconds. The harness counted 16 passed and 1 failed out of 17. The supplied tail lists successful packages such as internal/scm/gitlab, internal/telemetry, internal/tui, and internal/wizard, then ends with FAIL. It does not show which package or assertion failed, so the defensible finding is limited: the full command did not pass in our stated environment.
We ran the project in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and the Go 1.24 Bookworm image. The scan found 5 CI workflow files, no Dockerfile, and no conventional tests directory. Those facts describe commit c2a75d0. They do not measure agent accuracy, PR quality, or how safely the daemon behaves on a developer's long-lived repository.
Issue 845 puts the isolation claim under pressure
A disposable worktree is the right basic design because an agent can inspect and repair a branch without taking over the active checkout. The boundary still reaches local Git configuration and managed gate repositories. Open issue 845 reports core.bare=true appearing in the shared configuration of a real repository, which broke about 24 linked worktrees with Git's "must be run in a work tree" error.
That report names No Mistakes v1.57.0 and describes repeated occurrences on macOS arm64. Its author traced possible writers and proposed checking that Git's resolved directory exactly matches the intended bare gate before changing configuration. An issue report is not a maintainer-confirmed root cause. It is enough reason to pilot the tool away from a repository with valuable worktrees and to back up Git configuration before adoption.
Generated fixes still need an independent approval path
Open issue 725 describes another narrow but serious path: a test-step fixer changes the worktree, the rerun becomes clean, and the executor finishes without displaying the generated diff at the existing review gate. That contradicts the README's promise that changes affecting intent stay under human control. Until fixed and verified, every pushed commit needs review outside No Mistakes itself.
Long loops can also turn supervision into a quota problem. Issue 683 documents one run reaching 27 full rereviews and 8.2 hours under a high-effort agent. The report says most findings were new rather than repeated, so a clean final round never arrived. Put a hard limit on rounds, elapsed time, and spend. A branch that keeps attracting fresh repairs should return to a human instead of continuing overnight.
Version 1.57.0 is active, but activity is not proof of safety
GitHub showed 7,866 stars and 131 combined open issues and pull requests when fetched. The repository was pushed on August 26, 2026. Release v1.57.0 arrived on August 22 with Antigravity support, unified model and effort settings, timeouts around agent calls, branch-custody fixes, and a fail-closed change for invalid pull-request listings.
That release pace and same-day activity show active maintenance. They also mean an operating team should pin the binary and read changes before upgrading a tool that controls Git remotes and agent execution. Five CI workflows and a documented end-to-end fixture process are encouraging, yet our own 783-second suite still ended with 1 failure.
No Mistakes is worth a supervised trial when coding agents are already part of the daily workflow. Its local remote and explicit decision states solve a real coordination problem. The failed test run, issue 845's repository-damage report, and the missing diff gate in issue 725 keep it below the standard for an enforcement boundary.