Coding agent approval workflow · reviewed 2026-10-03

Do not make one approval screen solve two different jobs.

Direct answer: Execution permission answers whether an agent may perform an action. Change acceptance answers whether an exact verified candidate may become accepted project state. Mature workflows can need both, and mixing them can create approval fatigue or ambiguous accountability.

Execution permission

Agent products already provide strong controls here. Codex combines sandbox boundaries with approval policies and Auto-review. Claude Code uses permissions, sandboxing and auto mode to reduce repeated prompts. NVIDIA OpenShell lets operators review policy changes proposed by agents.

Change acceptance

Acceptance happens after a concrete candidate exists. A useful acceptance boundary should identify the exact candidate, show the relevant deterministic checks, and become invalid if the candidate changes after review.

Why approval fatigue matters

Both OpenAI and Anthropic publicly describe the cost of repeated approval prompts. That means “more prompts” is not automatically “more control.” Put human attention on consequential boundaries and keep routine work inside enforceable policy where appropriate.

Practical workflow

Bound the agent’s execution scope.
Let low-risk work proceed inside that scope.
Run deterministic checks on the candidate.
Show the exact candidate/diff.
Require human acceptance only at the real-state boundary.
Record what was accepted and what happened afterward.

StateHinge hypothesis