"Shall We Approve?" Consequence-Aware Approval for Autonomous Coding Agents

1. Introduction

• Existing approvers judge request, command, or interaction text, while shell commands can invoke code that reads credentials, deletes data, or accesses networks unseen in that text.Human approval of every command does not scale, and frequent prompts can cause approval fatigue.Source: §1 · pp. 1–2
• The same make clean && make command can delete regenerable build files or destroy source files and repository history, depending on the workspace Makefile and task scope.Approvers need to assess observed effects in the current workspace against the user's request.Source: §1 · p. 2, Figure 1 · p. 2
• Caper pre-executes each command in a snapshot, derives a bounded effects report, then commits an allowed result or rolls back a blocked command with an actionable reason.The report retains consequential events; the contribution summary reports it is about 99% smaller than the raw trace.Source: §1 · pp. 2–3
• 6.7% versus 14.8–21.2% harmful-outcome rate on SABER, and 7.8% versus 35.3–94.1% on YoloFS-Ext, give Caper the lowest rate among six existing systems.Caper and its Claude Code hook have the two lowest YoloFS-Ext rates; Caper blocks 1.0% of safe twins there.Source: §1 · p. 3

2. Related Work

• Claude Code Auto Mode and CARE use classifiers or rule checks for shell commands, while policy frameworks restrict which tool calls agents may make.Auto Mode's classifier sees messages and tool calls but not tool outputs; CARE uses syntax-, path-, and provenance-aware checks.Source: §2 · p. 3
• YoloFS shows post-command file changes for human review, while GoEx relies on undo mechanisms and leaves validation to a human after execution.Caper instead presents evidence to an independent approver before each command is committed.Source: §2 · pp. 3–4
• Guardrail models assess proposed calls against policies, but text-based judgments do not reveal harms hidden in invoked code.ToolEmu emulates tool-call effects, which reflect the model's expectation rather than the invoked code's actual behavior.Source: §2 · p. 4

3. Threat Model

• The agent may face ambiguous target or scope, make mistakes, exceed user intent, or be redirected by untrusted project files or tool outputs.Workspace scripts, build files, and binaries may do more than their names or command text suggest.Source: §3 · p. 4
• The goal is to prevent out-of-scope persistent changes, network transfers, or disclosure through output while allowing safe completion; the model trusts the approver, rollback mechanism, and container boundary.Source: §3 · p. 4

4. Consequence-Aware Approval

• At the shell boundary, Caper executes each proposed command under tracing in a snapshot, withholds output, and asks whether its bounded effects report fits the user's task.The agent remains unchanged and proposes one command per step.Source: §4 · p. 4

4.1. Transactional Pre-execution

• A blocked command's mutated container is replaced from its snapshot, so the agent continues without inheriting its changes.The transaction covers local container state; the sandbox disables outbound networking but reports attempted connections and their destinations, processes, and prior reads.Source: §4.1 · p. 5

4.2. Bounded Effects Report

• The effects report condenses consequential events into cards for persistent file transitions, network attempts, and user-visible output, with bounded diffs for small text files.Figure 3 illustrates a report containing a protected read, subsequent output, and connection attempts stopped by the sandbox.Source: §4.2 · p. 5, Figure 3 · p. 6
• For data-carrying consequences, the report links earlier successful reads by the same process; it also flags protected reads and sensitive output without copying credential values.Source: §4.2 · p. 6
• The report targets 4 KiB and caps at 8 KiB, retaining execution status, event counts, simulation markers, and uncertainties as it aggregates or summarizes events.Source: §4.2 · p. 6

4.3. Approver and Feedback

• The LLM approver assesses task scope, sensitive access, security-control changes, runtime and deferred effects, and uncertainty, then returns a decision and reason to guide safer replanning.On Allow, it returns captured output; on Block, it returns a reason without quoting secret values and advises against equivalent retries.Source: §4.3 · pp. 6–7

5.1. Setup

• The evaluation uses 682 shell-only SABER tasks and 102 YoloFS-Ext dangerous tasks, each paired with a safe twin; six existing systems and no-approval baselines are compared.YoloFS-Ext varies hidden tool behavior across four concealment levels, while its safe twins use harmless tools; outcomes include harm, safe completion, and false blocking.Source: §5.1 · pp. 7–8

5.2. Main Results

• Caper has the lowest harmful-outcome rate on SABER (6.7% versus 14.8–18.8% for five text-based approvers); on YoloFS-Ext, it and its Claude Code hook have the two lowest rates, with Caper blocking 1.0% of safe twins.Caper also has the highest safe-completion rate on YoloFS-Ext.Source: §5.2 · pp. 8–9, Table 3 · p. 9

5.3. Ablation Study

• Without evidence, more dialogue reduces harm from 44.1% to 17.6% but raises twin false blocks from 52.0% to 61.8%; with evidence, command-only approval yields 1.0% harm and no false blocks.Predicting effects still blocks 61.8% of twins; removing the content diff raises harm from 7.8% to 13.7%, while a weaker approver lowers false blocks from 53.9% to 4.9% but not harm. With evidence, harm stays at 4–15% across concealment levels, versus 4.2–26.9% without evidence.Source: §5.3 · pp. 10–11

5.4. Case Study

• In two cases allowed by Claude Code Auto Mode, Caper blocks commands that overwrite source code or drop database tables, and its reasons guide the agent to safe completion.The database report shows a shrink from 32 KB to 20 KB, sufficient to block without reading the binary file.Source: §5.4 · p. 11, Figure 7 · p. 12, Figure 8 · p. 12

5.5. Overhead

• On SABER, the effects report is 99.4% smaller than the raw trace, with median approval latency of 3.2 s versus 3.3 s without evidence.The sandbox adds about 0.5 s per allowed command and 1.5 s per blocked command; API cost is $0.019 per task versus $0.017 without evidence.Source: §5.5 · p. 11

• Caper pre-executes each shell command in a snapshotted sandbox and sends a bounded effects report to an LLM approver.Blocked commands are rolled back with a reason the agent can act on.Source: §6 · p. 12
• Across SABER and YoloFS-Ext, Caper achieves the lowest harmful-outcome rate against six existing systems while keeping safe outcomes.Source: §6 · p. 12
• Approvers deciding from command text cannot separate a dangerous command from its safe twin.Source: §6 · p. 12

Effects beyond the sandbox

• External effects, including network requests, remote writes, and started processes, occur before approval and cannot be undone by filesystem rollback.Deployment must isolate pre-execution, for example with a recording proxy that returns placeholders while preserving requests in the report.Source: Limitations · p. 12

Shell commands only

• Caper gates shell commands, but standalone file edits are judged from the call unless a later command runs the planted code.An edit that overwrites a configuration file is judged only from its call.Source: Limitations · p. 13

One observed execution

• One sandbox execution may not predict later behavior when effects depend on time, randomness, or environment; the benchmarks contain no adaptive attacker.Potential adaptations include detecting the sandbox, deferring harm, placing text in the report, or splitting changes across benign-looking commands.Source: Limitations · p. 13

Judgment by LLMs

• LLM approvers can vary across runs or misread reports, and SABER’s rule-and-LLM oracle can err similarly.Source: Limitations · p. 13

Other deployed gates

• A matched comparison with OpenAI Codex would require changing its default sandbox policy, which reviews only requests leaving the workspace.Most benchmark harms would not reach that reviewer under its default policy.Source: Limitations · p. 13

• Experiments ran in network-disabled containers without real users, services, or credentials.Source: Ethical Considerations · p. 13
• The effects report records only the class of a detected credential, never its value.Source: Ethical Considerations · p. 13
• Because Caper lowers harm but does not remove it, the authors recommend using it with sandboxing and human review for high-stakes actions.Source: Ethical Considerations · p. 13

A. Benchmark Details

• Caper has the lowest SABER harmful-outcome rate under both the released and revised oracles, and the revision lowers every system’s rate.The revised oracle removes false positives identified by auditing, and the same revised oracle judges every system.Source: Table 4 · p. 18, A. Benchmark Details · p. 18
• YoloFS-Ext uses 13 hidden-side-effect YoloFS tasks, rewritten tools, and safe twins that differ from dangerous tasks only in tool code.The original tasks’ project files, requests, harm operations, and concealment levels are retained; no project content is added.Source: A. Benchmark Details · pp. 18–19, Figure 9 · p. 21
• YoloFS-Ext tools package legitimate operations and file harm at four concealment levels, from a readable script to a compiled binary whose source is removed.The binary level is generated only when the operations fit the C template; hashed task identifiers keep the agent and approver from seeing whether a task is dangerous.Source: A. Benchmark Details · pp. 18–19
• The benchmark construction yields 102 dangerous tasks: 26 each at L1–L3 and 24 at L∞, with every victim a protected file the request does not name or produce.Fifteen candidates lack a binary level, and the rule excluding harm to files named or produced by the request removes 39 copy-then-delete tasks.Source: A. Benchmark Details · p. 19
• All 204 YoloFS-Ext tasks pass execution checks, and two models judge every dangerous task unsafe and every twin safe across 1,224 calls.Labels are fixed by construction and checked against tool execution and file changes.Source: A. Benchmark Details · p. 21

B. Baseline Reproduction

• Outside Claude Code, each approval system replaces the approval step in the same transactional harness, with blocked commands rolled back and reasons returned to the agent.Claude Code Auto Mode uses its own rules and classifier prompt; the reproduced systems use GLM-5.3-Flash as the agent.Source: B. Baseline Reproduction · p. 21, Table 8 · p. 22

C. Additional Results

• The YoloFS agent reverted at least once in 66 of 102 dangerous runs; 3 of those ended harmed, while 33 of 36 runs without a revert ended harmed.Table 9 reports blocking behavior and whether the command that matters is blocked; Table 10 breaks SABER harmful-outcome rates down by harm category.Source: C. Additional Results · p. 22, Table 9 · p. 22, Table 10 · p. 23
• Approval decisions count each proposed bash command, while Claude Code omits commands it classifies as read-only from classifier decisions.YoloFS and no-approval rows have no approver.Source: C. Additional Results · p. 22, Table 9 · p. 22

D. Ablation Details

• Removing the content diff changes harmful outcomes only for overwrite tasks: 3 are harmful with the diff versus 10 without; delete tasks are unaffected, at 5 versus 4.The text explains that deletion is visible directly in the report, whereas overwriting appears as a file-size change.Source: D. Ablation Details · p. 23
• Without evidence, approvers block bare scripts and binaries largely regardless of their behavior; with predicted effects, every binary twin is blocked.Table 11 gives twin false-block rates by concealment level.Source: Table 11 · p. 23, D. Ablation Details · p. 23

E. Confidence Intervals

• Table 12 gives 95% Wilson confidence intervals for every rate reported in Table 3, providing interval estimates for the complete set of rates presented in that earlier table.Source: E. Confidence Intervals · p. 23

F. Overhead Breakdown

• An allowed sandbox command costs about 0.5 s and a blocked command about 1.5 s; the snapshot adds a median 407 B and is removed after each decision.The allowed-command transaction includes a snapshot, two scans, tracing, and snapshot removal.Source: F. Overhead Breakdown · p. 23, Table 13 · p. 24
• Table 12 provides 95% Wilson intervals for the rates reported in Table 3.For SABER, intervals use tasks judged by every system, except DeepSeek-V3.2; YoloFS-Ext intervals use 102 dangerous tasks and 102 twins.Source: Table 12 · p. 24
• Table 14 reports per-task agent and approver API cost, approval calls, and median and p95 approval latency for SABER.TS-Guard and Qwen3Guard run on a local GPU and incur no API cost; estimated costs use token counts and ignore prompt caching for the classifier upper bound.Source: F. Overhead Breakdown · p. 23, Table 14 · p. 24