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

What a Pre-Action Check Actually Stops

A pre-action check runs before a tool call executes and decides whether it is allowed. It governs what an agent may touch, and never whether the change it wants to make is correct.

That distinction is the whole subject. Prevention limits blast radius, and blast radius is not the same thing as quality.

An agent can stay perfectly inside its permissions and still ship the wrong feature. No prompt catches that, because nothing about the action looked dangerous.

Which Controls Exist and What Each Blocks

Seven controls cover most setups. The table sorts them by which layer they sit in, because that determines what happens when the layer above is misconfigured.

Read the last column as a reliability score. Anything answering yes degrades under volume, and volume is the entire point of running agents.

Hooks are the most precise of the six. In Claude Code a PreToolUse hook fires before the tool call runs, and exiting with code 2 blocks it outright.

// a PreToolUse hook returning a deny decision instead of exit 2
{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Destructive command blocked by hook"
  }
}

// permissionDecision accepts: deny, allow, escalate
// escalate hands the decision back to the user rather than deciding for them

The escalate value is the one worth knowing. It lets a hook stay silent on routine calls and interrupt only on the cases you cannot decide programmatically.

What No Pre-Action Check Can Catch

Correctness. Every control above inspects the action an agent is about to take, and none of them knows what the finished change was supposed to do.

A permitted edit to a permitted file can still break checkout. The command looked ordinary because it was ordinary.

So the second half of the problem needs something that runs after the change exists. Kane CLI from TestMu AI covers that side, driving a real Chrome browser from a plain-language objective.

• Runs after the fact - it checks the built feature rather than the command that built it.
• Called by the agent - installed as a skill, the coding agent invokes it and reads the verdict.
• Gates in CI - the same objective runs headlessly, so a failure holds the merge.
• Leaves a record - each run writes an evidence pack a reviewer can open.

Command reference is in the Kane CLI introduction documentation. Why the check has to come from outside the agent is argued in can coding agents test their own code.

Where Each Control Fails in Practice

Every control on the table has a specific way it stops working. Knowing the failure mode matters more than knowing the feature.

• Permission modes - teams widen them after the third interruption and never narrow them again.
• Plan mode - the plan gets approved unread once the task looks routine.
• PreToolUse hooks - they match the command you thought of, not the equivalent one you did not.
• Sandboxes - credentials mounted into the container travel with whatever runs inside it.
• Protected paths - a rename moves a file out of the pattern that was protecting it.
• Branch protection - it holds, which is why it is the one worth configuring first.

The hook failure is the least obvious. Blocking a named command constrains one route to an outcome, not the outcome itself.

An agent that cannot call one command will often reach the same end state another way, without any intent to evade. Restricting the environment beats enumerating commands.

Why Permission Prompts Stop Working

Because they are a decision, and decisions get cheaper each time you make one. A prompt that appears fifty times a day is not a control, it is a keystroke.

Security teams have a name for this pattern from multi-factor push notifications. The mechanism is sound and the human in the loop is the part that degrades.

Two properties tell you whether a prompt will survive contact with real usage.

• Frequency - a prompt firing more than a few times a session trains the reflex that defeats it.
• Distinguishability - if the dangerous prompt looks like the routine one, nobody separates them under time pressure.

So reserve prompts for the rare and the irreversible. Everything routine belongs in a hook or a sandbox where no attention is required.

Which Settings File Wins

Harness controls are only as strong as the file they live in, and most teams configure the weakest one. Claude Code resolves settings through a fixed precedence chain. Repository instruction files run on a separate chain of their own, which agents md sets out per agent.

The top row is the one worth knowing. A managed policy cannot be widened by a developer having a frustrating afternoon, which makes it the only harness control with the durability of a repository rule.

Rules name a tool and what it may do. A deny entry is the useful half, because an allow list quietly grows and a deny list rarely does.

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Put the deny entries in the shared project file so they travel with the repository. Anything left in a personal file protects one machine.

How the Layers Stack

The layers matter because each one catches what the layer above missed. A harness control fails silently when misconfigured, and a repository control does not care how the agent was configured at all.

• Repository rules hold even if the agent is set up wrongly on someone's laptop.
• System sandboxes hold even if a hook has a gap in its pattern.
• Harness controls give the precision the outer layers cannot express.
• Post-action verification covers the correctness none of the three address.

Teams usually build this stack inside out, starting with the harness because it is the layer they just installed. Outside in is the safer order.

Mapping real incidents to the layer that would have stopped them makes the ordering concrete.

The last row is the one worth sitting with. It is the most common failure and no pre-action layer appears in the column beside it.

For how these controls differ between harnesses, our comparison of Claude Code vs Antigravity covers the permission and review models side by side.

Which Controls to Add First

Order by what survives a distracted human, not by what is quickest to switch on.

• Branch protection on main, requiring review before any merge.
• A sandbox or container so shell access cannot reach the host.
• A PreToolUse hook denying the handful of commands you never want run.
• Prompts reserved for the rare, irreversible cases only.
• An executed check after the change, gating the merge on evidence.

The first two need no agent configuration and cannot be widened in a moment of impatience. That is why they come before the more precise tools.

Prevention and verification answer different questions. A team with only one of them is protected against exactly half of what agents get wrong.

Prevention is only half the control surface. For the enforcement side, including the events a rule can bind to and the exit code that actually blocks an action, see Claude Code hooks.