Claude Code Approval Gates: When to Let Agents Run and When to Stop Them

The first instinct when deploying Claude Code in production: approve everything. Every file write, every command, every Git operation — a human reviews first. This lasts about one day before the team realizes they’ve created a system requiring more human effort than doing the work manually.

The second instinct: approve nothing. Let the agent run freely. This works until something goes wrong, and then the conversation becomes about why nobody was watching.

The right answer is in between, and finding it requires understanding what actually needs oversight.

The Approval Taxonomy

Every Claude Code operation falls into four categories:

Always allow. Operations with no blast radius and easy reversibility: reading files, running tests in a sandbox, listing directories, checking Git status, querying read-only APIs. Gating these creates friction with zero security benefit.

Allow with logging (notify gate). Operations with minor side effects within expected scope: writing files in the working directory, creating Git commits on a feature branch, running linters, installing development dependencies. Log and make visible, but don’t stop the agent.

Allow with approval (approval gate). Operations with significant side effects on shared resources: pushing to Git, creating pull requests, modifying infrastructure, writing to production databases, sending external communications. A human confirms before proceeding.

Never allow (deny gate). Operations exceeding the agent’s intended scope: pushing to main/production branches, deleting infrastructure, modifying IAM policies. Blocked by policy regardless of approval. If the agent tries, that’s an alert.

The commands that always need a gate

Some operations are dangerous enough that they should never run without a human in the loop, no matter how confident the agent is. Practitioners converge on the same short list — gate (or hard-block) these by default:

• rm -rf, chmod, and filesystem destruction
• sudo and privilege escalation
• ssh / scp to other hosts
• kubectl apply / kubectl delete
• terraform apply / terraform destroy, cdk deploy / cdk destroy
• aws … delete-*, security-group, and IAM changes
• package installs (npm install, pip install) that pull arbitrary code

The cost of skipping this is not hypothetical. In early 2026 a team let Claude Code “clean up unused infrastructure” in auto mode; it ran terraform destroy against a workspace pointed at production and wiped roughly two and a half years of data. There was no gate on terraform destroy — because nobody predicted that exact command. That’s the trap with hand-written denylists: you only block the disasters you imagined. An approval gate on the category (destructive infra) turns that incident into a one-tap “Deny” in Slack instead of a post-mortem. This is why the gate belongs at a control plane the agent can’t reconfigure, not in the agent’s own settings.

Implementing Approval Gates in Slack

Slack is the natural approval interface because it’s where engineers already work. A well-implemented gate:

1. Agent hits an operation requiring approval
2. Gateway sends Slack message with full context: operation, agent session, developer who launched it, why the agent wants to do it
3. Authorized approver clicks “Approve” or “Deny”
4. Gateway receives callback, allows or denies the operation
5. Decision logged with approver identity and timestamp

What the message should include:

Agent Request: Push to feature/auth-refactor
Session: sess_a8f3b21c (jordan@company.com)
Project: backend-api
Files changed: 4 (auth/middleware.ts, auth/types.ts, tests/auth.test.ts, README.md)
Commit: "Refactor auth middleware to use session tokens"
[Approve] [Deny] [View Diff]

The “View Diff” button lets the approver review changes without leaving Slack. The approver has enough context to make an informed decision in under 30 seconds.

Avoiding Approval Fatigue

The biggest risk isn’t too few gates — it’s too many. When every operation requires approval, approvers click “Approve” without reading. This is worse than no gates: it creates false security while adding latency.

Signs of fatigue: Average approval time under 10 seconds (nobody is reading), approval rate over 99% (gates aren’t catching anything), developers complaining agents are too slow, approvers auto-approving from mobile notifications.

Prevention: Gate only operations where denial is a realistic outcome. Group related operations into a single approval (approve the entire push, not each file individually). Track metrics on approval times and rates — deteriorating numbers indicate fatigue.

Timeout Behavior

When nobody responds to an approval request, what happens?

Block forever: Agent waits indefinitely. The work stalls completely if the request comes in after hours.

Auto-approve after timeout: Undermines the entire point. Attackers just wait.

Auto-deny after timeout (recommended): The operation is denied, the agent is notified and can attempt an alternative approach or stop. Fail closed. This is the right default.

Escalate then deny: Primary approver gets 15 minutes. No response → escalate to secondary. No response within 30 minutes → auto-deny. Balances responsiveness with security.

Building Toward More Autonomy

Approval gates should evolve as confidence in the agent increases.

Phase 1: Gate all write operations, all Git pushes, all infrastructure changes. You’re learning what the agent does.

Phase 2: After a month, review approval logs. Operations with 100% approval rate → convert to notify gates. Operations that were denied → keep the gates, they’re working.

Phase 3: Different policies for different projects. The internal tooling project needs minimal gates. The production API needs strict gates.

Phase 4: Track the agent’s history per project. 50 successful sessions with zero incidents and zero denials → consider loosening gates. An incident → tighten and require additional approval for that operation type.

A Mature Setup

For a team of eight with well-tuned policies:

• Read operations: no gate (100+ per session)
• Feature branch commits: notify (10-20 per session)
• Feature branch pushes: approval (2-3 per session)
• Pull request creation: approval (1 per session)
• Production infrastructure: approval from team lead (rare)
• Direct push to main: denied (never)

The agent runs at full speed for 95% of operations. The 5% requiring approval are meaningful decisions where a human check adds real value. Approvers handle 3-5 requests per session — manageable without fatigue.

This is the balance. Not security theater where everything is gated and everyone rubber-stamps. Not cowboy mode where nothing is controlled. Thoughtful gates at the right decision points, with a path toward more autonomy as confidence grows.

FAQ

Which AI agent commands should require human approval? Gate operations that are high-blast-radius or hard to reverse: production deploys, terraform apply/destroy, kubectl delete, rm -rf, sudo, IAM/security-group changes, data deletion, external communications, and financial transactions. Let read-only and sandboxed operations run freely so the gate stays meaningful.

How do human-in-the-loop approvals work for Claude Code? The agent hits a gated operation; the control plane pauses it and sends an approval request — with full context — to Slack, Telegram, or a dashboard; an authorized human approves or denies; the decision is logged with identity and timestamp. Fail closed: if no one responds, auto-deny.

Won’t approval gates slow the agent down? Only if you over-gate. Gate the ~5% of operations where denial is a realistic outcome; let the other 95% run. A well-tuned setup surfaces 3–5 approvals per session — meaningful checks, not rubber-stamps.

What happens if nobody approves in time? Auto-deny (fail closed) is the correct default — auto-approving on timeout defeats the purpose, since an attacker just waits. Optionally escalate to a secondary approver before denying.