Choosing an Agent
no-mistakes is pipeline-agent-agnostic by design: the gate should mean the same thing regardless of which supported agent backend you prefer.
It is not runner-free.
Every validation run requires a supported native agent binary, the agent: cursor or agent: devin ACP alias, or an explicit acp:<target> through acpx.
The default agent: auto setting picks the first supported native agent or ACP alias available on your system.
The coding agent that calls no-mistakes axi drives approval gates, but it does not automatically become the pipeline agent that performs review, evidence testing, documentation, combined documentation-and-lint housekeeping, or fixes.
Those jobs run in the daemon’s disposable worktree through the configured pipeline agent.
A validation-step agent inspects, fixes, and returns only its assigned phase; delivery requirements in user intent remain acceptance context, but the outer executor alone performs the other validation, push, PR, and CI phases.
If that step attempts pipeline control, no-mistakes returns error.code: nested_gate_context; the agent must return control to the outer executor, while read-only no-mistakes axi status, no-mistakes axi logs, help, and no-mistakes doctor remain available.
The agent is responsible for the parts of the gate that benefit from judgment: code review, evidence-oriented test validation, test or lint detection when you have not configured explicit commands, auto-fixing, and setup-wizard suggestions when you leave prompts blank.
Pipeline agent prompts also include a workspace-boundary preamble and an execution-context section with the exact worktree directory and path contract.
It tells agents to keep intentional source, project, user-data, and system file writes inside the disposable worktree, use that exact path prefix when tools require absolute paths without guessing or re-resolving paths, avoid mutating system state such as Homebrew packages, /Applications, or global tool config, and treat that boundary as prompt steering rather than true enforcement.
The only intentional out-of-worktree write it allows is test evidence under the run’s managed evidence directory when a testing prompt asks for it.
Incidental temp or cache writes from normal development tools are still allowed.
The same preamble bounds the read side: agents may read outside the worktree and run read-only commands, but must not run filesystem-wide searches such as find / or mdfind /, and must not hunt the host filesystem for an installed tool. When a needed tool is not on PATH and no repository-local path is supplied, agents report the missing tool and blocked work in their normal result rather than searching the machine. That rule stops the search and any verification that needs the tool; an agent still does the rest of its task, including edits. The Test step has its own live-scenario guidance.
Testing prompts also ask agents to remove transient working-tree artifacts they created, such as downloaded models, caches, build outputs, large binaries, or generated data directories, before reporting completion.
How to choose quickly
- Leave
agent: autoif one good agent is already installed and you do not need repo-specific behavior. - Set a repo-level
agentoverride when one codebase clearly works better with a different tool. - Use an ordered fallback list when you prefer one agent but want no-mistakes to try another if the first process is unavailable.
- Set explicit
commands.lintand a targetedcommands.testif you want deterministic local baseline command execution regardless of agent choice. Test always follows its optional baseline with agent-driven end-user scenarios; remote CI owns broad regression. See Test for the live-validation contract.
That last point matters: explicit repo commands make the baseline predictable, while the agent establishes whether the requested behavior works in the real product.
That testing invocation is expected to leave only intentional source or test-file changes in the worktree, while preserving requested evidence files under the dedicated evidence directory.
That directory is always outside the worktree and is reaped by no-mistakes on a bounded retention schedule; GitHub.com/GHEC PRs upload supported screenshots and recordings, and can also publish an orphan evidence branch with test.evidence.store_in_repo. See test.evidence for its location, attachments, and cleanup.
Supported agents
| Agent | Binary | Protocol |
|---|---|---|
| Claude | claude | Subprocess per invocation, JSONL streaming |
| Codex | codex | Subprocess per invocation, JSONL events |
| Grok Build | grok | Subprocess per invocation, Messages-compatible JSONL streaming |
| Antigravity | agy | Subprocess per invocation, NDJSON stream-json events |
| Rovo Dev | acli | Persistent HTTP server, SSE streaming |
| OpenCode | opencode | Persistent HTTP server, SSE streaming |
| Pi | pi | Subprocess per invocation, JSONL events |
| Copilot | copilot | Subprocess per invocation, JSONL events |
| Cursor | cursor-agent + acpx | cursor-agent acp through the ACP bridge |
| Devin | devin + acpx | devin acp through the ACP bridge |
| ACP target | acpx | Optional user-installed ACP bridge |
Runner requirements
A complete gate never degrades silently when its configured pipeline agent is unavailable. The daemon resolves the effective agent before creating pipeline step records, and the run fails immediately with setup guidance if the configured binary cannot run. This refusal also applies when deterministic test or lint commands are configured because review and documentation always require agent judgment, while rebase, PR, and CI paths may need an agent to resolve conflicts, generate content, or fix failures.
| Surface or capability | Works without a runnable pipeline agent? | Behavior |
|---|---|---|
Install, init, daemon lifecycle, status, runs, and doctor | Yes | Local setup and diagnostics remain available. doctor reports that gate validation is unavailable. |
| Start or rerun a validation gate | No | The run fails before any pipeline step starts. |
| Review | No | Requires agent judgment and structured findings. |
Test with commands.test | No, as part of a full gate | The command is deterministic, but the gate refuses before steps start rather than presenting command-only validation as a complete pass. |
Test, with or without commands.test | No | The optional command is only a baseline; the agent must derive and drive end-user scenarios. |
| Document | No | Requires the agent to discover and update documentation gaps. |
Lint with commands.lint | No, as part of a full gate | The command is deterministic, but the full gate still requires an agent. |
Lint without commands.lint and all fix rounds | No | The document step performs the initial combined housekeeping pass, and an agent is still needed for fallback assessment or code changes. |
| Push, PR, and CI as part of a gate | No | They run only after the required validation steps, and PR or CI paths may invoke the agent themselves. |
Antigravity and Gemini setups
Running the gate from Antigravity or another Gemini-based coding environment does not make that calling model available to the daemon automatically. Choose one of these supported setups:
- Install any supported native agent CLI and leave
agent: auto, or select it explicitly in~/.no-mistakes/config.yaml. - Install both
cursor-agentandacpx, then leaveagent: autoor selectagent: cursor; likewisedevinandacpxforagent: devin. - Install
acpx, confirm that the Gemini ACP target works locally, and configureagent: acp:gemini.
agent: acp:gemini
# Optional when acpx is not on PATH.acpx_path: C:\path\to\acpx.exeRun no-mistakes doctor afterward and look for a successful gate validation line.
Doctor checks the global agent configuration; each run performs the authoritative check again after applying any trusted repository-level agent override.
If the calling environment exposes neither a supported native CLI nor a working ACP target, it can still inspect and respond to existing AXI state, but it cannot start an honest validation gate by itself.
Setting the agent
Global default
agent: autoPer-repo override
agent: codexRepo config takes precedence over global config.
Ordered fallback list
# ~/.no-mistakes/config.yaml or .no-mistakes.yamlagent: [codex, grok]Optional ACP target
If you install acpx separately, you can opt into any ACP target with the acp: prefix, for example agent: acp:gemini.
agent: auto probes native agents and first-class ACP aliases (cursor and devin), and never auto-selects arbitrary acp:<target> entries.
acp:omp (Oh My Pi over ACP) is additionally a verified gate agent under disable_project_settings: its default launch neutralizes the target repository’s context files, rules, skills, and extensions. See that reference entry for the exact mechanism and the override that fails closed.
The agent field reference owns the exact resolution order, fallback-list filtering and retry semantics, and the failure behavior when no entry is runnable.
Where agent choice matters most
Changing agents most directly affects:
- review quality and tone
- test evidence collection, plus test and lint detection when commands are not configured
- how good auto-fix attempts are for your stack
- branch name and commit subject suggestions in the setup wizard
It does not change the pipeline order or the meaning of a passed gate.
Driving no-mistakes as an agent
The primary way to put a change through the gate from inside a coding agent is the /no-mistakes skill.
A skill-aware tool like Claude Code supports two invocation modes.
Use bare /no-mistakes to validate existing committed work.
Use /no-mistakes <task> to have the agent first do the task, commit only that task’s changes on a feature branch, then run the pipeline with the task text as --intent.
In both modes, it resolves low-risk findings on its own and stops to relay anything that needs your decision.
Grok Build is a pipeline runner, not a driving-skill target. no-mistakes init installs the /no-mistakes skill for Claude Code and agents that use the vendor-neutral .agents convention; the init reference owns its locations and supported consumers.
If your home directory consolidates .claude and .agents with symlinks, init follows the links and keeps the skill reachable from both logical paths.
Re-run no-mistakes init after an upgrade to refresh that skill, including overwriting stale SKILL.md content from an older binary.
Older versions vendored the skill into each initialized repo’s .claude/skills and .agents/skills; those copies are no longer needed, and init prints a notice when it finds one so you can remove it.
The skill drives no-mistakes axi, a non-interactive command surface that prints TOON to stdout and progress to stderr.
When CI is ready - either its registered checks are green or the trusted default-branch config declares no_ci: true with no registered checks - and known mergeability is clear, axi run and axi respond return outcome: checks-passed with a help line pointing at the PR instead of waiting for a human merge. An empty check result without that declaration is not ready; see the CI step reference for the readiness rules.
That is a successful agent stopping point: report that the PR is ready and ask the user to review and merge it.
By default the run stays active there and keeps monitoring the PR, so the agent runs no command and must never hand-rebase.
Successful outcomes also instruct the agent to summarize the run for the user.
When the pipeline applied fixes, successful outcomes include a fixes table listing each fix so the agent can acknowledge what it missed and the user can review them.
Under ci.release_after_checks_pass the run finishes at that verdict instead: run.status is checks_passed, the run released its worktree, and nothing is left watching the PR, so if that PR later falls behind the default branch or hits a merge conflict, the update is a fresh no-mistakes axi run on the updated head; this run will not rebase or re-push it. Everything below describes the default monitor.
When that monitor sees an actual conflict it rebases onto the base, resolves it, revalidates from Review because rebasing cannot prove continuity with the reviewed head, and re-pushes the branch through Push, so no agent or user action is needed.
On GitHub, a clean PR whose base requires branches to be up to date (mergeStateStatus: BEHIND) still reports checks-passed and waits for a human to bring it up to date; only when the repository opts into ci.rebase_behind does the monitor give it the same rebase, once its checks are green and the base has held still for one poll.
A PR that is merely behind a base without that rule needs nothing either, since the platform merges it.
The one exception is when that monitor is no longer running - the PR was closed, the run was aborted or superseded, it idle-timed-out, or its auto-fix attempts were exhausted - in which case see no-mistakes rerun for the restart conditions.
A run that failed before Push only because an agent invocation failed - a provider error, a usage limit, or the agent process exiting - can instead continue from its failed step with no-mistakes axi retry --run <id>; it refuses with the failed proof whenever continuing is not provably safe.
The agent must not use no-mistakes axi run to refresh a still-active PR: after checks-passed it reattaches to the running monitor with HEAD unchanged and returns the monitor output without rebasing.
In task-first mode, if the repo is on the default branch, the skill tells the agent to create a feature branch before committing because the gate validates committed history on a non-default branch.
The agent should inspect git status before changing or committing anything, preserve unrelated pre-existing uncommitted changes, and commit only the changes that belong to the user’s task.
Agents can also call no-mistakes axi directly:
no-mistakes axi run --intent "the user's goal"no-mistakes axi statusno-mistakes axi sync --checkno-mistakes axi syncno-mistakes axi sync --recoverno-mistakes axi sync --adopt-publishedno-mistakes axi respond --action approveno-mistakes axi respond --run <id> --action approveno-mistakes axi logs --step review --fullno-mistakes axi abortno-mistakes axi abort --run <id>no-mistakes axi retry --run <id>Before any post-pipeline local commit or fresh run, read branch_sync and follow its exact next_action.command.
A sync action runs no-mistakes axi sync first.
A recover_custody action is ordinary no-mistakes axi sync --recover to take a still-available preserved head, or no-mistakes axi sync --recover --keep-local when that head is unavailable and you are discarding the missing commits, or when a bound archive preserves divergent later work while custody returns at the reported required head; never substitute one action for the other. See no-mistakes rerun for the alternative validation path and its refusal conditions.
A recover_remote_rewritten action is exact no-mistakes axi sync --recover after a terminal run whose push target was force-rewritten outside the pipeline: it anchors the superseded pipeline head and rebinds only the recorded push binding to the re-verified live head, and refuses --keep-local, a target or live head that changes during recovery, an unanchorable head, and a merged or closed PR. See no-mistakes axi sync.
An adopt_published action is no-mistakes axi sync --adopt-published: it verifies the configured push target already has the exact rebased local head, then updates only the stale gate lane. A target mismatch or target change refuses without replacing that lane.
A branch_sync.state of user_owned means the run went terminal before changing the submitted head and cancellation released the branch: it is immediately usable and needs no sync action.
When next_action.code is continue_active_run, run the reported command and keep driving the active run.
If synchronization is blocked, process that state instead of improvising reset, stash, merge, rebase, force, or branch replacement.
Then commit follow-up work on top so every pipeline fix commit remains in the branch.
The full driving protocol - how to read the home view and gate: objects, when to respond, fix, approve, or relay ask-user findings, and how to interpret axi status fields like awaiting_agent and active_steps - is owned by the skill itself and by the live axi output.
Each axi response carries version-matched help lines for its state, and no-mistakes axi run --help and no-mistakes axi respond --help describe the loop authoritatively for the installed binary, so agents driving a gate never need this page open.
The CLI reference documents each axi command and output field for humans.
Binary resolution
When the daemon is running through a managed service, its PATH comes from your login shell environment on macOS and Linux plus common user, Homebrew, and system binary directories; on Windows it reuses the current process environment.
If native agent discovery does not resolve the binary you expect, check ~/.no-mistakes/logs/daemon.log and set an explicit override; Environment the daemon sees owns the full resolution story.
Six global config fields tune resolution and invocation, and the Global Config Reference owns each one:
agent_path_override- custom binary paths per native agent, plus the default native binary-name table.agent_config- model and reasoning effort per agent in one common spelling, mapped down to each harness’s own mechanism, with the full per-harness mapping table and the precedence rule against raw flags. Opt-in per-run Pi profiles pin those knobs for one validation run.agent_args_override- extra CLI flags per native agent for anythingagent_configdoes not cover, such as service tier or permission mode, including the reserved-flag rules and smart defaults. Keep both global-only; they reflect your local agent setup rather than repo policy.acpx_path- the bridge binary path for explicit ACP targets and first-class ACP aliases.acp_registry_overrides- raw ACP target commands, including replacements for alias defaults such ascursor-agent acp, plus their availability-probing rules.agent- theautoresolution order and ordered fallback-list semantics.
Review session reuse
With the default session_reuse: true, Claude, Codex, Grok, Pi, and Antigravity keep one durable review-fixer session per run when every configured fixer for that run supports resume. A later-round fixer that cannot resume makes all fixer turns cold. Resume failures still fall back to a fresh fixer session instead of skipping the fix turn. Pi stores its native fixer transcript in Pi’s session directory; no-mistakes persists only the minimum session identity needed to resume it.
Review turns always run in fresh, session-free invocations: a rereview certifies fixes that implement the previous review turn’s findings, so it must never resume the session that prescribed them.
The session_reuse field reference owns the exact reuse, fallback, privacy, and restart-recovery semantics.
Agent interface
All agents implement the same interface. Each invocation receives:
- Prompt - the task description (review this diff, fix these findings, etc.), prefixed during pipeline runs with the workspace-boundary steering and exact execution-context contract described above
- CWD - the worktree directory
- Environment - the daemon environment plus non-interactive Git overrides (
GIT_EDITOR=true,GIT_SEQUENCE_EDITOR=true, andGIT_TERMINAL_PROMPT=0) so agent-invoked Git commands do not hang on editors or credential prompts - JSONSchema - optional structured output schema for typed responses
- OnChunk - callback for streaming text output to the TUI
- OnLifecycle - callback for native subprocess start, exit, retry, fallback, and output-liveness activity; control events reach step logs and AXI active-step status, while throttled output liveness updates status without flooding the log
- Session - optional no-mistakes-owned native session identity for review-fixer reuse
- Purpose - local performance label for the pipeline duty served
Each invocation returns:
- Output - structured JSON output; when
JSONSchemais requested, adapters require that it returns some structured output, while pipeline steps validate their own output contracts. Text-parsed fallbacks are validated against the requested schema and may usenullfor optional fields. - Text - raw text output
- Usage - token counts (input, output, cache read, cache creation)
- SessionID and Resumed - the adapter-native session identity and whether this invocation resumed it, when supported
- Model and Provider - adapter-reported serving metadata when available
When structured output comes from final text, no-mistakes validates JSON fences and concluding bare JSON objects extracted from prose against the requested schema. It accepts inline or unclosed JSON fence forms, but rejects multiple valid candidates and fails closed when fenced and bare candidates differ; semantically identical fenced and bare candidates are accepted. A bare object followed by substantive prose is not treated as a verdict, while trailing provider tool-protocol residue after a complete object - markup whose tags wrap no words, or punctuation alone, never prose or markup around real words - is. When a model splits one answer across adjacent bare objects - separated by nothing but whitespace or a single comma - the merged object is accepted only when their keys are disjoint and the union validates, so two competing verdicts are never combined; a concluding split with disjoint keys whose union still does not validate fails with its own dedicated error rather than a generic schema error, while a run that repeats a top-level key is competing values and stays terminal. Two bare objects that each validate on their own remain a terminal ambiguity for the standard adapters; ACP targets are the one exception, keeping the last valid bare object instead of failing (see the ACP aliases below).
One-shot subprocess agents (Claude, Codex, Grok, Pi, Copilot CLI, Antigravity, and acpx) are invocation-scoped. After no-mistakes starts one, it terminates any remaining child processes when the invocation exits, fails, or is cancelled, so agent-spawned test workers, build watchers, and dev servers do not survive the step. Step logs record their process lifecycle, including start and exit lines with the PID, and AXI status exposes that PID while the subprocess is still active. Persistent server agents (Rovo Dev and OpenCode) use their managed server lifecycle instead.
Transient API and network failures, stochastic prose turn endings, transient tool-call or permission validation errors, and final-text parse failures whose remedy is a fresh turn (provider protocol residue after a complete object, or a split answer the parser could not fuse) are retried up to three times with exponential backoff. Network failures include DNS errors such as EAI_AGAIN, connection failures, and request timeouts. Claude applies this policy to fresh and resumed invocations, including terminal API errors without an HTTP status; a reported non-transient HTTP status still fails immediately, even if the diagnostic quotes a network error. Provider quota and free-usage-limit errors stop retries within that agent, even when a backend marks them retryable; see quota-aware routing for switching agents. A retry never extends the invocation’s deadline: when the time left is shorter than the failed attempt took, the retry is skipped and the step fails with the original error. Retry messages are recorded as lifecycle activity for native subprocess agents, falling back to the streaming text path for direct callers that do not supply OnLifecycle.
Intent extraction
For explicit intent supplied to axi run, see the CLI reference’s intent input transports and whitespace handling and the Intent step’s acceptance-criteria semantics.
Review checks the diff against those criteria, and a change that removes required behavior or adds forbidden behavior becomes an ask-user finding instead of being resolved automatically.
Otherwise, when intent.enabled is true, no-mistakes reads recent local transcripts from Claude Code, Codex, OpenCode, Rovo Dev, Pi, and the GitHub Copilot CLI during the intent pipeline step.
It matches sessions against non-deleted changed files when present, falls back to all changed files for all-deletion diffs, summarizes the likely author intent with the configured pipeline agent, and includes that summary as an untrusted, low-confidence hint in rebase fixes, review checks and fixes, test detection, evidence validation, and fixes, lint detection and fixes, documentation checks and fixes, CI auto-fixes, and PR prompts. Publication of the generated Intent section is controlled by the repository’s trusted pr.publish_intent, tightened further for individual runs by axi run --no-publish-intent or globally by intent.publish_intent: false in global config. Every one of these controls is tighten-only, and no caller-side setting can publish intent on a repository whose trusted config disabled it. The full intent always reaches the rebase, review, test, lint, documentation, and CI prompts listed above; under the caller-side omission the PR-drafting prompts receive no intent text at all, so the public PR can carry neither the section nor a paraphrase of it.
Transcript readers collect user and assistant text messages but exclude tool call output.
They read Claude Code transcripts from ~/.claude/projects, Codex metadata from ~/.codex/state_*.sqlite plus referenced rollout files, OpenCode messages from $XDG_DATA_HOME/opencode/opencode.db or ~/.local/share/opencode/opencode.db, Rovo Dev sessions from ~/.rovodev/sessions, Pi transcripts from ~/.pi/agent/sessions, and GitHub Copilot CLI sessions from ~/.copilot/session-state.
Sessions are eligible when they come from the same working directory or an equivalent Git checkout with the same common Git directory or normalized remote URL.
ACP transcripts are not currently read for intent extraction.
When deterministic matching leaves multiple plausible sessions, no-mistakes may ask the configured pipeline agent to choose among them using the matching file paths and sanitized transcript packet files. That disambiguation prompt receives the same exact execution-worktree path contract as other pipeline prompts; transcript packets remain sanitized data, not instructions.
The selected transcript text is then sent to the configured pipeline agent for summarization during the intent step, so intent extraction may incur additional agent or API invocations.
Before disambiguation or summarization, no-mistakes excludes tool output, redacts likely secrets, strips common prompt-control markers, and clamps long transcripts while preserving the beginning and end.
no-mistakes stores derived intent summaries and matching metadata in ~/.no-mistakes/state.sqlite, including the source, session ID, and match score on each run plus cached summaries for matching transcript sessions.
It does not store raw transcript text in its database.
The step logs accepted candidate match diagnostics, then logs the matched source, score, and sanitized inferred intent when a transcript matches.
Use intent.disabled_readers to disable specific transcript sources, or set intent.enabled: false to opt out entirely.
Claude
Spawns a claude subprocess for each invocation with --output-format stream-json. The print-mode user prompt is sent as text on stdin rather than placed in the process arguments. By default it also adds --dangerously-skip-permissions, unless you already set your own Claude permission flag through agent_args_override. Reads JSONL events from stdout. Supports native structured output via --json-schema. A nonzero exit with empty stderr reports the plain-text stdout tail, the result subtype, or no stderr or stdout output instead of a blank message. A nonzero exit after a successful result event that carries the requested output uses that result, except when the step requires completed children.
For review-fixer reuse, Claude starts a stream-json session and resumes it with claude -p --resume <id>.
Codex
Spawns a codex subprocess for each invocation with exec --json. When structured output is requested, no-mistakes also writes a normalized schema file and passes it with --output-schema. By default it also adds --dangerously-bypass-approvals-and-sandbox, unless you already set your own Codex approval or sandbox flag through agent_args_override. Reads JSONL events. Structured output is returned from the final agent_message text and uses the common text fallback described above when needed.
Codex model and reasoning effort belong in global agent_config.codex, which renders them as -m and -c model_reasoning_effort. Other config overrides, such as -c service_tier="priority", belong in agent_args_override.codex.
For review-fixer reuse, Codex resumes the reported thread with codex exec resume <id> <prompt>.
That resume command has a narrower flag surface than codex exec, so a resume that rejects an override falls back to a fresh fixer session rather than skipping the fix turn.
Grok Build
Spawns a grok subprocess for each invocation using a permission-restricted prompt file and --output-format streaming-messages-json. Native structured output is requested with --json-schema; the terminal structured_output, session identity, model, and usage fields are read from the Messages-compatible result event. Review-loop reuse resumes the reported Grok session with --resume.
Without an explicit pin, Grok uses its current configured default model. See agent_config for model and effort configuration and native mapping.
Grok is not available to a repository with disable_project_settings: true, because Grok 1.0.5 still discovers native project instructions and .grok project surfaces; the gate fails closed before launch. See disable_project_settings for the security boundary. System-prompt, alternate-agent, working-directory, worktree, and restore flags are reserved so global overrides cannot redirect the managed invocation.
Antigravity
Spawns an agy subprocess for each invocation with --print <prompt> --output-format stream-json, plus --dangerously-skip-permissions (always present; agent_args_override cannot suppress it). By default it also adds --print-timeout 24h to prevent premature pipe closure during long-running turns, unless you already set a timeout flag (-t or --print-timeout) through agent_args_override. Reads NDJSON events from stdout, streaming step_update text deltas to the TUI. Structured output is requested with a temporary --json-schema file and read from the terminal result’s structured_output. Result precedence is terminal-authoritative: structured_output outranks the terminal result’s response, which outranks the streamed deltas.
For review-fixer reuse, Antigravity resumes the reported conversation with --conversation <id>. A pruned or unknown conversation id starts a fresh conversation instead of failing the turn.
Usage accounting includes agy’s reported thinking_tokens as reasoning tokens.
--conversation, -c/--continue, the print/output flags, and the permission flag are reserved so global overrides cannot redirect the managed invocation.
Rovo Dev
Starts a persistent HTTP server (acli rovodev serve) on first use and reuses it across invocations. If a reused server refuses a connection, no-mistakes discards it and retries with a fresh server. Any agent_args_override.rovodev flags are inserted before no-mistakes’ managed serve flags. Neither the serve command nor the REST session API takes a model or reasoning parameter, so no-mistakes cannot map those knobs for Rovo Dev; the agent_config reference owns the refusal and escape-hatch semantics. Communicates via REST API and SSE streaming. Each invocation creates a session, sends the prompt, streams results, then deletes the session. Structured output is handled by injecting schema instructions into a system prompt, then parsing the final text with the common fallback described above while allowing null for optional fields.
OpenCode
Starts a persistent HTTP server (opencode serve) on first use and reuses it across invocations.
The binary’s major version selects the protocol before any session or prompt is created; OpenCode 1 and 2 are supported.
Any agent_args_override.opencode flags are inserted before no-mistakes’ managed serve flags; model flags do not belong there because opencode serve rejects them.
Model and reasoning effort come from agent_config.opencode.
OpenCode 2 runs with a private per-server credential and a parent-owned stdin lease (serve --stdio).
The credential is used for health checks and API requests, never put in command arguments, and removed from the environment before OpenCode tools inherit it.
Health is verified through /api/info, not the retired /global/health endpoint.
Each invocation creates a fresh session at its own worktree location, selects the model and variant when creating that session, admits its prompt, waits for execution, and reads every page of projected messages.
Live SSE events provide progress, but a disconnected or lagging stream never proves completion or absence of tool effects.
The final message projection supplies the authoritative answer and per-step token usage.
Because the V2 tool-using session API has no native JSON-schema format field, the schema is included in the prompt and the final text is validated with the common text fallback described above, including nullable optional fields.
A provider failure never becomes a successful answer merely because it left valid-looking JSON behind.
An admitted V2 execution is not automatically replayed after an uncertain or failed outcome; cancellation interrupts and deletes only the invocation’s own session.
OpenCode 1 retains its synchronous message API, model/variant message fields, native info.format JSON-schema output and existing tool-evidence-gated retry/fallback behavior.
See internal/agent/opencode*.go for the authoritative version-specific contracts.
Pi
Spawns a pi subprocess for each invocation with --mode json. Cold invocations add --no-session; with session_reuse: true, review-fixer turns create and resume one Pi session per run via --session <UUID> when the configured fixer roles support resume. A non-resumable later-round fixer makes those turns cold; see the later-round role overrides reference.
Model and reasoning effort come from agent_config.pi unless the run has an opt-in per-run Pi profile. Native mapping is --model and --thinking.
Reads JSONL events from stdout and streams incremental text deltas to the TUI.
When structured output is requested, no-mistakes loads a temporary extension with a terminating no_mistakes_output tool whose parameters carry the schema and require provider-side strict JSON-schema generation.
The tool declaration carries only the schema keywords the Review schema uses (type, properties, items, required, enum, description), because a provider can refuse a strict tool over any other keyword; a keyword left out, such as the commit summary’s maxLength, is still enforced on the returned output.
This uses Pi’s constrained tool sampling and terminating structured-output tool, not the JSON event mode as a model-output constraint.
This strict path needs Pi 0.82.0 or later (read from pi --version; a prerelease such as 0.82.0-beta sorts before 0.82.0), a provider/model supporting strict JSON-schema tools, and Pi arguments that leave the tool selection open.
Pi applies --no-tools (-nt) and a --tools (-t) allowlist to extension tools too, so with either flag in agent_args_override.pi the model cannot see no_mistakes_output.
Otherwise the invocation uses the prompt-inlined schema: the schema goes into the prompt and the final text response is validated with the common text fallback described above. A provider/model that refuses strict tools is retried once on that path and then stays on it for the agent’s lifetime.
The step log names which path each structured invocation ran.
On the strict path, a run that ends without calling no_mistakes_output as its only final tool call is retried by the bounded invocation retry loop; if retries exhaust, it remains a structured-output rejection, so Review’s bounded schema rerun applies. A pi exited: ...: fetch failed error is retried only when its stderr does not indicate authentication, access denial, or quota exhaustion; those failures stop retries within that agent.
Either way the adapter validates the result against the same schema, keeping required fields and the existing nullable-optional-field contract unchanged.
The extension is invocation-scoped and works with --no-extensions.
Invocations without a schema retain the ordinary final-text path.
Copilot CLI
Spawns a copilot subprocess for each invocation with -p <prompt> --output-format json.
It also adds --no-color and --no-ask-user so the run is non-interactive, plus --allow-all-tools (required for non-interactive mode) unless you already set your own Copilot permission flag through agent_args_override.
Any agent_args_override.copilot flags are inserted before no-mistakes’ managed flags, so user choices take effect. Prefer agent_config.copilot for model and reasoning effort; it renders the same --model and --effort flags, and a raw flag here still wins over it.
Reads JSONL events from stdout, streaming incremental assistant.message_delta text to the TUI and capturing the final assistant.message content.
The Copilot CLI has no output-schema flag, so when structured output is requested no-mistakes injects the JSON schema into the prompt and validates the final text response with the common text fallback described above.
ACP aliases
ACP aliases are first-class agent names that resolve to ACP targets.
agent: cursor and agent: devin are shorthands for acp:cursor and acp:devin, not separate native backends. Their default commands and override rules are documented under global agent.
Because aliases still run through acpx, they use acpx_path for the bridge binary and share the same ACP prompt and structured-output behavior as agent: acp:<target>.
Unlike arbitrary acp:<target> entries, aliases may participate in agent: auto when their availability checks pass.
The Global Config Reference owns ACP availability, bridge-path, command-override, and equivalent-spelling deduplication rules.
ACP via acpx
ACP support is optional and requires a separately installed acpx binary.
Use agent: acp:<target> to run a target known to acpx, for example agent: acp:gemini.
When the target matches a first-class alias such as acp:cursor, no-mistakes supplies that alias’ default raw command.
Configure custom target commands in the Global Config Reference.
no-mistakes invokes acpx with JSON output, approve-all permissions, denied non-interactive permission prompts, and the repo worktree as --cwd.
Structured output is handled by appending the requested JSON schema to the prompt and validating the final assistant text with the common text fallback described above.
A model set under agent_config for an alias or acp:<target> is passed as acpx’s own --model, so ACP targets can be pinned to an explicit model. acpx exposes no reasoning-effort surface, so effort is refused for ACP names rather than silently ignored.
Devin CLI
agent: devin runs Devin CLI through acpx and uses the stored devin login; no-mistakes never signs in or changes Devin configuration. For model ids and effort, see agent_config; for project-instruction suppression, see disable_project_settings.
Devin starts each session in its accept-edits mode. Read-only commands run without a prompt, and a shell command that writes files raises an ACP permission request, which acpx grants under no-mistakes’ approve-all posture. Devin reports usage over ACP, but its figures cover only the turn’s latest model request, not the sum across every request in that turn. Recorded token counts for multi-step Devin turns therefore undercount what the turn consumed.
Checking agent availability
Run no-mistakes doctor to inspect individual native and ACP runner binaries and to check the effective global agent configuration:
$ no-mistakes doctor ✓ git ✓ gh ✓ data directory ✓ database ✓ daemon running ✓ claude – codex (not found) – grok (not found) – rovodev (not found) – opencode (not found) – pi (not found) – copilot (not found) – antigravity (not found) – acpx (not found) – cursor (not found (cursor-agent, acpx)) – devin (not found (devin, acpx)) ✓ gate validation claude is runnable✓ = available, – = not found (optional), ✗ = problem detected.
The standalone acpx, cursor, and devin rows inspect the default binary names.
The gate validation line is the decisive result: when the configured global runner is unavailable, doctor fails because a complete gate cannot validate without it.
See the Global Config Reference for ACP availability and probing behavior.
Every new validation run resolves its effective agent again after applying any trusted repository-level override.