Pre-Action Checks for AI Coding Agents: Tools and Patterns

The best pre-action check tools for AI coding agents are the controls built into the agent harness itself: permission modes, plan review, and pre-execution hooks, backed by sandboxed execution at the OS level and protected paths at the git level. A pre-action check is any control that runs before the agent acts. It inspects a proposed command, edit, or tool call and decides whether it proceeds, gets rewritten, or stops for a human. That is a different job from post-action verification, which runs after the change exists and asks whether it is correct.

Keeping those two jobs separate is the organizing principle of this guide, and we call it the two-gate model:

• Pre-action gates prevent damage. They stop the deleted database, the force-push to main, the leaked credential, the edit to a file the agent had no business touching. They are cheap, deterministic, and they fire in milliseconds.
• Post-action gates prove correctness. Tests, browser checks, and CI take the change the agent was allowed to make and answer a question no pre-action gate can: does it actually work?

Teams that run agents in production code run both. A pre-action gate cannot tell you the checkout button stopped working, and a test suite cannot un-drop a table. The failure mode we see most often is a team that invests heavily in one gate and assumes it covers the other.

The rest of this article walks through the seven mechanisms worth knowing, roughly ordered from the agent harness outward: approval prompts, plan review, hooks, sandboxes, git-level rules, CI required checks, and the post-action browser verification that completes the picture. Each entry covers what the mechanism actually intercepts, because "guardrail" is doing a lot of vague work in most writing on this topic.

What counts as a pre-action check

A pre-action check evaluates an action the agent has proposed but not yet executed. The evaluation can be:

• Interactive: a human approves or rejects a prompt.
• Deterministic: a rule or script allows, denies, or rewrites the action with no human involved.
• Structural: the environment makes the dangerous action impossible, so no decision is needed at all.

All three appear below. Structural controls (sandboxes, branch protection) are the strongest because they hold even when the agent is confused or a prompt injection is steering it. Rules in a system prompt or a CLAUDE.md file are not pre-action checks: they shape what the agent tries, but nothing enforces them. In Claude Code, for example, permission rules are enforced by the harness, not by the model, and that distinction is the whole point.

The seven pre-action check tools and patterns

1. Permission modes and approval prompts

The baseline pre-action check in every serious agent harness is the approval prompt: the agent proposes a command or edit, and a human says yes or no before it runs. What makes this a tool rather than a chore is the mode system that decides which actions prompt. Claude Code ships permission modes set via defaultMode in settings: default (prompt on first use of each tool), acceptEdits (auto-accept file edits, still prompt for risky commands), plan (read-only analysis), and stricter or looser modes for special environments. Alongside modes, allow/ask/deny rules give per-tool precision: Bash(git push:*) can require approval while Bash(git status) runs freely. Other harnesses ship equivalents under different names. The pattern to copy: broad categories by mode, sharp edges by rule, and deny for anything you never want proposed at all.

2. Plan mode review

Approval prompts gate one action at a time. Plan review gates the whole approach. In plan mode the agent can read code and search the repo but cannot edit files or run mutating commands; it produces a plan you approve before any execution begins. This is the highest-value pre-action check for large or ambiguous tasks, because the most expensive agent failure is not a bad command, it is thirty minutes of confident work in the wrong direction. Reviewing a plan takes two minutes; reviewing a 40-file diff built on a wrong assumption takes an afternoon. Use it for refactors, migrations, anything touching auth or payments, and any task where you cannot state the expected diff shape in advance. We cover the workflow in detail in Claude Code plan mode. Skip it for small, well-specified fixes, where the planning round-trip costs more than it saves.

3. PreToolUse hooks

Hooks are the programmable pre-action check: your own script runs before every matching tool call and decides its fate. In Claude Code, a PreToolUse hook is configured in settings.json with a matcher on the tool name ("Bash", "Edit", regex like "mcp__github__.*" for MCP tools) and receives the full tool input as JSON on stdin. The hook can block by exiting with code 2 (stderr becomes the explanation the agent sees), or return JSON with a permissionDecision of allow, deny, or ask, and can even rewrite the tool input via updatedInput before execution. That last part matters: a hook can transparently swap npm test for your faster test runner, or append --dry-run to anything scary. Because hooks are deterministic scripts, they enforce policy the model cannot talk its way around: block edits to migrations/, deny any command containing a production hostname, require an issue reference before git commit. Full walkthrough in Claude Code hooks.

4. Sandboxed execution

Prompts and hooks gate what the agent asks to do. A sandbox limits what any process it spawns can do, which is a stronger guarantee: a Python script the agent writes and runs is invisible to permission rules, but not to the OS. Three tiers, in increasing isolation:

• OS sandboxes. Claude Code's built-in sandboxing restricts the Bash tool's filesystem and network access using OS primitives (Seatbelt on macOS, bubblewrap on Linux), with allowlists for paths and domains. With sandboxing on, safe commands can run without prompting because the boundary substitutes for the prompt.
• Containers and VMs. Dev containers or disposable VMs give full isolation, and are the only environments where auto-approving everything is defensible.
• Worktree isolation. A git worktree gives each agent its own working copy on its own branch. It is not a security boundary, but it structurally prevents two agents from clobbering each other and keeps a runaway session out of your checked-out state.

5. Protected paths and branch rules

Git hosting gives you pre-action checks that hold even if the agent's own guardrails fail, because they are enforced server-side at push time. Branch protection on main blocks direct pushes and force-pushes regardless of which tool, agent, or human attempts them. GitHub rulesets can restrict changes to specific file paths, so deploy/, .github/workflows/, or a lockfile cannot be modified by a push at all. CODEOWNERS requires a designated human's review before anything touching a listed path merges. The pattern for agent work: agents commit only to feature branches, every change reaches main through a pull request, and the paths that could hurt you (CI config, infrastructure, migrations) carry both a path rule and a code owner. This layer costs nearly nothing to set up and is the one most teams already half-have.

6. CI required checks

Required status checks sit at the boundary between the two gates. The check itself (tests, lint, type-check, build) is post-action verification: it runs on a diff that already exists. But marking it required turns it into a pre-merge gate: the merge is the action being blocked, and no human override short of an admin bypass lets an unverified agent change into main. For agent-written code this is the single highest-value configuration change in most repos, because it converts "someone should look at this" into "this cannot land otherwise." What belongs in the required set, and how to keep it fast enough that agents iterating on failures do not stall, is the subject of quality gates for AI pull requests and CI/CD for agent-written code.

7. Post-action browser verification

The final entry is not a pre-action check, and that is the point: it is the complement the first six cannot replace. Every gate above can pass while the app is broken, because "this action is safe to take" and "this change is correct in the browser" are different questions. Shiplight (disclosure: Shiplight is our product) covers the second one. It installs into coding agents as a browser MCP server plus Skills, one-line install, and gives the agent eyes and hands in a real browser: after a change, /shiplight verify loads the app and confirms the flow the change was supposed to affect still works. Verifications become intent-based YAML tests in your repo, self-healing, and transpile to standard Playwright so there is no lock-in. Details in verifying AI-written UI changes and the coding agents overview. If your stack has entries 1 through 6 and nothing here, you have an agent that cannot hurt you and also cannot tell you whether it helped.

Which gate for which risk

Read the table top-down when triaging an incident: if the damage happened at execution time, you were missing a pre-action gate; if it shipped and users found it, you were missing a post-action one.

What pre-action checks cannot catch

Pre-action checks evaluate actions, not outcomes. An edit to CheckoutForm.tsx that renames a field and silently breaks form submission is, by every pre-action measure, a perfectly safe action: an ordinary file, an ordinary edit, no dangerous command in sight. Every permission mode allows it, no sensible hook denies it, the sandbox is irrelevant, and branch rules wave it through on a feature branch. The change is safe to make and wrong in the browser, and only the post-action side can tell you that. This is also why tightening pre-action gates past a certain point buys nothing: you add friction to every action without adding any ability to detect a bad outcome. Whether agents can close that loop on their own code is a real question, and we take it up in can coding agents test their own code. The inverse limit holds too: no test suite runs early enough to stop terraform destroy. Budget for both gates, and spend the deterministic, cheap controls up front and the correctness checks behind the change.

Frequently Asked Questions

Related Reading

• Claude Code hooks: the full guide to writing the PreToolUse hooks covered in entry 3.
• Claude Code plan mode: the plan-review workflow and when to reach for it.
• Quality gates for AI pull requests: what belongs in the required-check set at merge time.
• CI/CD for agent-written code: pipeline design when most commits come from agents.
• The testing layer for AI coding agents: how post-action verification fits into the agent stack.
• Verifying AI-written UI changes: the post-action side of the two-gate model in practice.

External references: Claude Code documentation on hooks and permissions.