Approval Gates for AI Agent Build Commands
What you’ll learn
- Why production-oriented builds should be separated from ordinary verification commands
- How to analyze why a command ran beyond the requested scope
- How to write a rule that requires explicit approval before risky operations
Put an Approval Gate in Front of AI Agent Build Commands
The expectation–result gap appeared when a navigation task continued into npm run build, which generates production-oriented artifacts. A local build is not itself a production release, but this repository treats it as an operation requiring explicit approval. Separate ordinary verification from approval-required commands in advance, then choose controls with the necessary strength, such as instructions, permissions, or hooks.
By the end of this article, you will have practical criteria for answering “How should ordinary verification be separated from builds and publication operations that need explicit approval?” in your own context.
Why Build Commands Need Explicit Approval
While asking AI to make a change to the site, a production build command ran at a point I had not intended. This article records how that happened and the rule I introduced to make recurrence less likely.
A Production Build Ran During a Navigation Change
I was asking AI to adjust the navigation structure of the site. After several files were modified and I was reviewing the changes, AI ran npm run build as part of that flow.
npm run build generates production-ready output from the site’s configuration and code. In this repository, a separate hosting deployment pipeline publishes that output. The local build and the production build therefore need to be treated as separate actions.
What I had asked for was a navigation adjustment. I had not asked for a production build.
Why AI Ran That Command
From AI’s perspective, running a build after finishing file changes is a natural next step. The sequence of modify, build, and verify is a common development pattern, so AI can move in that direction without an explicit instruction.
The problem was that AI’s judgment of “what comes next” moved ahead of my own decision point. Commands that affect a live environment should not be run without confirmation, regardless of how natural they appear in context.
Run Production Builds Only After Explicit Approval
Based on this experience, I added the following to the project rule file (CLAUDE.md):
Do not run
npm run buildwithout explicit user approval.
This rule prevents AI from automatically running a build as part of a modification flow. When a build is needed, I explicitly say “please run the build” before it is executed.
For regular preview checks, I use npm run dev. This runs only in the local environment and does not affect the production site.
Summary: Separate Autonomous Commands from Commands That Require Approval
Commands that affect a live environment should have an explicit confirmation step, even when they appear to be the natural continuation of a task. AI acts based on context, so the scope and limits of that context need to be clearly defined in advance.
Deciding in advance which commands AI can run autonomously and which require approval is a practical step toward safer collaboration.
Start by listing the project’s main commands and attach approval conditions to operations that affect external state, artifacts, time, or cost. The relationship between build and deployment differs by repository, so do not copy this project’s npm run build rule unchanged into another environment.