agentic-preflight

agentic-preflight

Stop your coding agent from pushing unverified work.

Agentic Preflight checks a coding agent's work before it is pushed. It works with Codex, Claude Code, Cursor, OpenCode, and Amp. It guides the coding agent already working in your repository through review, documentation, lint, and test stages, then records the result against the exact commit. Its pre-push hook blocks the normal push path when that evidence is missing or stale.

• Use the agent you already have. The core CLI calls no model and needs no model API key.
• Make every stage visible. Skips, failures, findings, and approvals remain part of the recorded run instead of disappearing into a prompt transcript.
• Bind green results to the code that earned them. A changed commit, configuration, or intent cannot inherit unrelated evidence.

Of 408 merged pull requests across four of the author's own repositories from August 3 to September 6, 2026, 323 record an Agentic Preflight run. The dogfooding case study reports what that record shows and what it does not.

Quickstart

You need Git 2.38+, Python 3.11 through 3.13, and uv. Install the CLI and the integrations for the coding agents you use:

uv tool install agentic-preflight
agentic-preflight integrations install codex claude cursor opencode amp

Remove the integration names you do not use.

Then initialize each repository you want to protect:

cd your-repo
agentic-preflight init
git add .agentic-preflight.toml
git commit -m "Configure Agentic Preflight"

init writes a commented configuration file and installs an advisory pre-push hook. Review the generated configuration before starting a run because its setup, lint, test, and optional command-review entries execute with your user privileges.

Make and commit your product change, then ask your coding agent to invoke $agentic-preflight in Codex or /agentic-preflight in Claude Code. The installed skill drives the run, presents any findings, and follows each command returned by the CLI.

If you try to push the changed commit before its run is green, the hook stops the push and tells you how to start or resume verification. After the run passes, the agent shows the target remote, branch, commits, and risk before publication.

The agent pushes only when you asked it to or your standing instructions permit it; see push and pull-request authorization. Set [gate] mode = "manual" when only a person should run the final Git command.

The installation guide covers source installs, upgrades, project-scoped skills, other Agent Skills clients, and removal.

What Agentic Preflight adds

Agentic Preflight complements prompts, ordinary Git hooks, hosted CI, and human review. It does not replace them.

Prompt instructions can ask an agent to review its work and run tests, but the resulting conversation is not a record bound to a commit. Traditional hooks run deterministic commands well, while hosted CI validates code after publication. Agentic Preflight joins those checks into an ordered, resumable workflow before push and records what happened against the commit that passed.

That distinction matters when:

• an agent reports a successful command from an earlier revision;
• a fix changes code after review or testing;
• repository policy requires documentation review or independent review;
• a rebase changes commit identity; or
• a high-risk path requires a specific human-approval mode.

Agentic Preflight is advisory by design. It makes missing or stale evidence visible in the normal workflow, but it is not a security boundary and a person can bypass the local hook with git push --no-verify.

What happens during a run

Agentic Preflight moves the change through one ordered workflow:

review -> documentation -> lint -> test -> merge-back -> gate -> push

At the start of a run, the agent supplies your objective and acceptance criteria. When origin exists, Agentic Preflight fetches it and rebases the validation worktree onto the fresh base before review, or merges the base in when a rebase would change what the branch lands. Every agent-facing workflow command returns one JSON object with the single next legal command, so an interrupted run can resume from recorded state.

The stages provide different checks:

• Review inventories changed hunks and non-text files, then requires the reviewer to account for the complete snapshot. Findings remain recorded with their disposition.
• Documentation checks configured documentation for claims made stale by the change.
• Lint and test run the repository's configured commands and record their exit codes and output hashes. Documentation- and CI-only changes skip the software test command through an explicit recorded transition. Applicable tests complete locally before publication; hosted CI validates the proposed integration separately.
• Merge-back and approval verify that the reviewed content matches the source branch, derive risk from repository policy and findings, and disclose the publication target.
• Push atomically publishes the branch and its Git-note attestation. Automatic PR mode then lets the agent create or reuse a GitHub pull request and monitor its checks; manual PR mode returns a compare URL instead.

Equivalent-content rebases can reuse review and documentation evidence when their inputs still match. Applicable lint and test stages run again in every new run, even for identical trees. Keep the producer and protected verifier on the same version; see the fingerprint contract.

Pull-request merge polling and post-merge cleanup are disabled by default. Set [pr] automated_cleanup = true to opt in.

Run agentic-preflight status in the source worktree to inspect or resume its run. Use agentic-preflight status --all to inventory runs across linked worktrees.

Configure repository policy

Commit .agentic-preflight.toml at the repository root. A section in it replaces the matching section of the user-wide ~/.config/agentic-preflight/config.toml as a whole. Use it to set:

• the protected base branch and lint/test commands;
• blocking finding severities and independent command-review policy;
• documentation paths and generated-file exclusions;
• path-based risk and the required human-approval mode;
• in-place, reusable, or strict validation worktrees; and
• automatic or manual push and pull-request behavior.

Unknown keys are errors; retired [ci] and [reuse] sections are ignored with a warning. Remove those sections and [hook] enabled when upgrading from 0.6.0; see the 0.7 upgrade guide. Commit configuration changes before starting the run they should affect; each run snapshots its resolved configuration. See the configuration reference for every option and a complete example.

Warning: A repository can configure setup, lint, test, and independent-review commands that execute with your privileges. Run Agentic Preflight only in repositories whose code and build commands you are willing to execute.

Choose a validation worktree

The default in_place mode validates in the current checkout. It suits a clean, dedicated one-agent/one-PR worktree and can reuse that checkout's installed dependencies.

Set [worktree] mode to reusable or strict when validation should leave the source checkout untouched. Isolated validation worktrees do not inherit .venv, node_modules, .env, or other ignored files. Configure setup_command for dependencies and copy_files for required ignored files. The worktree-modes guide explains the tradeoffs, concurrency model, secret handling, and recovery behavior.

Enforce attestations in CI

A successful merge-back writes a versioned JSON attestation as a Git note on the exact commit. The attestation records review coverage, finding dispositions, stage results, policy, and the inputs that determine whether evidence still applies after a history rewrite.

The local hook checks the commit being pushed. A protected-base GitHub workflow can also verify the attestation and enforce the configured high-risk approval mode before merge. This requires forge configuration; committing .agentic-preflight.toml alone does not change branch protection. See Portable attestations and CI enforcement for setup and verification commands.

Architecture, evaluation, and evidence

The user workflow above is backed by design records, executable tests, and published evaluation material. Follow the question you want to investigate:

The implementation uses real Git repositories in its integration tests rather than mocking Git behavior. CI rejects overall test coverage below 85% and installs the built wheel as a uv tool before invoking the CLI. The contributor guide describes the local development workflow.

Limits

Agentic Preflight is an advisory pre-push check, not a security boundary.

• A person can bypass the local hook with git push --no-verify.
• The push-confirmation token is not a secret. It prevents an accidental tool-driven push but does not stop an agent with shell access from invoking Git directly.
• An attestation proves what the configured stages reported. It does not prove that the reviewer understood the change, and it replaces neither hosted CI nor human review.
• Git notes are mutable. Anyone allowed to update the notes ref can replace an attestation.

Set [gate] mode = "manual" if the CLI must refuse to perform the final push itself. Read the limits guide before relying on attestations or evidence reuse for policy enforcement.

Requirements

• A supported macOS, Linux, or Windows and Python combination from the compatibility policy
• Git 2.38+
• A POSIX shell when a configured command needs shell interpretation or its program cannot be resolved directly; on Windows, Git for Windows provides it
• gh when the agent will create pull requests, inspect hosted checks, or verify merges

Help and development

Use the support guide for help and security-reporting routes. Contributors should start with the contributor guide.

Agentic Preflight is Apache 2.0 licensed. It was created by @elanthus with development contributions from OpenAI Codex and Anthropic Claude.