Plan Mode vs. Auto-Accept: How Execution Mode Selection Becomes a Safety Primitive in Coding Agents

A developer argues that coding agents' execution mode selection — plan mode versus auto-accept — should be treated as a per-task safety primitive rather than a uniform global default, since most agent failures occur at the approval gate. The piece outlines plan boundaries, locking plans to a specific commit SHA to detect drift, and rollback strategies such as shadow branches with automatic cleanup, and proposes that agents learn from failure patterns to automate mode selection.

Most coding agent failures happen at the approval gate. Teams pick a default execution mode plan or auto-accept and apply it uniformly. Plan mode wastes time on trivial edits. Auto-accept ships silent regressions when context drifts. The real control surface is treating mode selection as a per-task decision, not a global preference. Claude Code, Cursor, Windsurf, and Grok Build all expose this pattern: agents can either propose changes for review plan mode or write directly to disk auto-accept . The distinction maps cleanly to financial authorization workflows. Plan mode is dual authorization. Auto-accept is a pre-approved transaction limit. Both have failure modes. Both require observability. This article examines execution mode selection as a safety primitive. It covers plan boundaries, state persistence between approval and execution, rollback strategies when auto-accept breaks builds, and the signals that distinguish safe automation from human-required review. Plan mode prevents file writes until a human approves the batch. The agent reads the codebase, generates a diff, and presents it as a proposal. No mutations occur until the operator confirms. What constitutes a plan unit: The boundary is task-scoped, not file-scoped. An agent might propose changes to six files in one plan if they all serve a single feature. The operator reviews the entire batch or rejects it. State persistence between proposal and execution: This is where most plan mode implementations fail. If the agent doesn't detect drift, it applies a diff to the wrong base and creates merge conflicts. The correct pattern is to lock the plan to a specific commit SHA and reject execution if HEAD moves. Auto-accept grants write authority from the start. The agent mutates files as it generates changes. No approval gate exists. The operator sees results after the fact. When auto-accept is safe: When auto-accept is dangerous: The failure mode is silent corruption. The agent writes invalid code, the developer doesn't notice until CI fails, and the team spends time debugging agent output instead of shipping features. Auto-accept requires a rollback plan. If the agent breaks the build, the operator needs a fast path to undo. Common rollback implementations: | Strategy | Mechanism | Latency | Failure Mode | |---|---|---|---| | Git revert | Agent commits each change, operator reverts the commit | Seconds | Loses work if multiple changes landed in one commit | | Shadow branch | Agent writes to a feature branch, operator merges or deletes | Minutes | Requires branch hygiene, can accumulate stale branches | | Checkpoint snapshots | Agent saves filesystem state before each mutation, operator restores | Seconds | High disk usage, doesn't integrate with version control | | Undo buffer | Agent tracks inverse operations delete line X, restore line X , operator replays | Milliseconds | Breaks on non-invertible changes file deletion, lossy transforms | The best pattern is shadow branches with automatic cleanup. The agent creates a branch per task, writes changes, runs tests, and either merges if tests pass or deletes if tests fail . The operator never sees broken state in the main branch. The decision to use plan mode or auto-accept should depend on measurable risk factors. Agents that learn from failure patterns can automate mode selection. Signals that indicate plan mode: Signals that indicate auto-accept: The agent can track these signals per task type and build a decision model. After 100 formatting tasks with zero failures, auto-accept becomes the default. After three failed refactors in a shared module, plan mode becomes mandatory. The most effective teams use both modes in a single session. The agent starts in plan mode for exploration, switches to auto-accept for mechanical steps, and returns to plan mode for risky changes. Example workflow: The mode switch happens based on task phase. Exploration and design decisions require human review. Mechanical implementation steps run autonomously. Switching modes mid-task introduces coordination risk. The agent must track which changes landed in which mode and prevent inconsistent state. Coordination requirements: The correct implementation is a state machine: python class AgentExecutionMode: def init self : self.mode = "plan" Start in safe mode self.pending plan = None self.auto accept log = def propose plan self, changes : if self.mode = "plan": raise InvalidStateError "Cannot propose while in auto-accept" self.pending plan = changes return changes def execute plan self : if not self.pending plan: raise InvalidStateError "No pending plan" apply changes self.pending plan self.pending plan = None def switch to auto accept self : if self.pending plan: raise InvalidStateError "Cannot switch with pending plan" self.mode = "auto accept" def auto accept change self, change : if self.mode = "auto accept": raise InvalidStateError "Not in auto-accept mode" apply changes change self.auto accept log.append change def switch to plan self : self.mode = "plan" The state machine prevents the agent from proposing a plan while uncommitted auto-accept changes exist. It also prevents auto-accept writes while a plan is pending review. Execution mode selection is a security control. Auto-accept bypasses human review, so it must respect the same boundaries as any automated write operation. Security requirements: The enforcement layer is a file access policy. The agent checks every write operation against a whitelist. Auto-accept writes to source files are allowed. Auto-accept writes to .github/workflows are blocked. Both modes have distinct failure modes. Understanding them helps teams choose the right default. Plan mode failures: Auto-accept failures: The mitigation strategy is to use plan mode as the default and whitelist specific task types for auto-accept. The whitelist grows as the agent proves reliability. Coding agents in production need execution mode configuration at multiple levels: organization, repository, and task. Configuration hierarchy: The agent checks all three levels before executing. The most restrictive policy wins. If the organization disables auto-accept, no repository or task can override it. Use plan mode as the default for all coding agents. It prevents silent failures and keeps developers in the loop. Switch to auto-accept only for task types with proven reliability: formatting, linting, documentation updates, and mechanical refactors. Avoid auto-accept for: Use plan mode for: The best teams build observability into mode selection. Track success rates per task type. Automate the decision when confidence is high. Require human review when uncertainty is high. Execution mode selection is not a preference. It is a safety primitive. Treat it like transaction limits in financial systems: start conservative, expand boundaries as trust grows, and always maintain rollback capability.