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

Caper pre-executes each proposed shell command in a snapshotted sandbox, gives an LLM approver a bounded effects report, commits allowed commands, and rolls back blocked ones with a reason.

Existing automated approvers decide from the request and command text, so they do not observe what a shell command invokes or how the current workspace changes its effects. A command such as make clean && make can delete only build artifacts in one workspace and source files plus repository history in another. Systems that observe file changes assess them after execution, leaving remediation to the agent or a human. Caper targets this gap by deciding on observed consequences before committing them.

Caper snapshots the task container and pre-executes each proposed shell command inside it under system-call tracing, with output held back until approval. From the trace, it derives a bounded effects report that keeps persistent workspace changes, connection attempts, command output, and protected reads, attributed to the process and files involved. An LLM approver receives the user task, interaction history, raw command, and effects report, and returns Allow or Block with confidence and a short reason. On Allow, the executed state is kept and output is returned; on Block, the container is restored to the snapshot and the reason is returned so the agent can replan.

• Caper achieves the lowest harmful-outcome rate on SABER and YoloFS-Ext while blocking 1.0% of safe twins in YoloFS-Ext. §Abstract
• On SABER, five text-based approval systems leave 14.8–18.8% of tasks harmed, against 19.7% without approval and 6.7% for Caper. §5.2
• Replacing Claude Code Auto Mode's built-in classifier with Caper as the approval hook lowers the harmful rate from 14.8% to 10.0% on SABER and from 62.7% to 6.9% on YoloFS-Ext. §5.2
• Caper without the effects report blocks 61.8% of safe twins; with the effects report it blocks the harmful command in 84.3% of dangerous tasks while blocking only 1.0% of safe twins. §5.2
• YoloFS's agent reverts in 66 of 102 dangerous runs; of 36 runs without a revert, 33 end harmed, and YoloFS leaves 35.3% harm, four times Caper, with only 22.5% of dangerous tasks safely completed against 60.8% for Caper. §5.2
• On SABER, the effects report has median size 0.9 KB and p95 2.6 KB versus 62.5 KB for the raw trace, a 99.4% reduction; median approval latency is 3.2 s versus 3.3 s without evidence, and API cost is $0.019 versus $0.017 per task. §5.5

• The paper states that rollback restores only the container file system, so effects that leave the container, such as network requests, remote writes, or started processes, happen before approval and cannot be undone; deployments must isolate pre-execution, for example with a recording proxy.
• The paper states that Caper gates shell commands only; other tools such as file edits state their change in the call, and an edit that does harm by itself is judged only from the call.
• The paper states that the report describes one observed execution; tools depending on time, randomness, or environment may behave differently on rerun, and adaptive attackers could detect the sandbox, plant text in the report, or split harm across commands; neither benchmark contains such an attacker.
• The paper states that judgment by LLMs can vary across runs and misread the report, and that SABER's oracle can err in the same way.

• Caper leaves the agent unchanged and intervenes at the shell boundary for each proposed command in state s_t. §4
• Each task runs in its own Docker container with networking disabled and memory and process limits; the container is snapshotted before the command, which executes under strace -f with a timeout. §4.1
• Allow discards the snapshot and returns captured output; Block removes the mutated container, starts fresh from the snapshot, and returns a reason so the agent can replan; the command is executed exactly once. §4.1
• The effects report retains only consequential events: persistent workspace changes, connection attempts, command output, and protected reads, attributed to the process and files involved; probe accesses are subtracted by count. §4.2
• The approver receives the user task, interaction history, raw command, and effects report, and returns JSON Allow or Block with confidence and a short reason. §4.3
• The approver assesses scope, credentials, protected security controls, runtime effects, deferred behavior, and uncertainty; the packet is framed as evidence rather than instruction. §4.3
• In Case 1, Caper blocks ./tool when the diff shows src/app.js overwritten from 29 B to 11 B; the agent then copies source files and deploys safely. §5.4
• In Case 2, Caper blocks make migrate when the report shows app.db shrinking from 32 KB to 20 KB; the agent backs up the database and runs only the migration script. §5.4