Home / Security and data

Responsible automation: reversible first, failure reported, fix requested

An automation in Auto, Accept Edits or Bypass Permissions mode runs most deletions the moment the command is reached, without confirmation: build the human checkpoint before the destructive command. A silent failure never announces itself, and a blocked fix is requested, not merely noted.

The official Claude Code documentation describes two distinct behaviours for Accept Edits mode: it approves file edits in advance, along with a fixed set of system commands such as mkdir, touch, rm, mv, cp and sed, as long as they stay inside the working folder.

Human oversight is not automatic everywhere

The official documentation lists six permission modes: Manual (the starting mode of claude -p), Accept Edits, Plan, Auto, Don't Ask and Bypass Permissions. Only Manual mode systematically asks for confirmation before a destructive command runs inside the working folder; Plan and Don't Ask remain at least as restrictive. But since late September, an interactive terminal or VS Code session starts by default in Auto mode on every plan, not Manual mode, a mode that runs most actions with simple background safety checks rather than a confirmation on every command. An automation launched in Auto, Accept Edits or Bypass Permissions mode therefore no longer asks the confirmation question for most file commands: it runs the deletion the moment the command is reached, not the moment someone reviews it. A documented exception still stands regardless, across every mode including Bypass Permissions: an rm or rmdir deletion that targets a critical path is never approved in advance. The human checkpoint must therefore be built into the automation's own scenario, before the destructive command, rather than assumed to exist by default in the tool, or in the permission mode setting alone.

Checkpoint before execution:
1. Describe the planned action (which files, which folder)
2. Mark an explicit pause that waits for approval
3. Execute only after this approval

What October changed

In the desktop app and in VS Code, in Bypass mode, a dangerous rm or rmdir is now denied at once with a suggestion to rewrite it, instead of opening a prompt: an unattended session carries on instead of staying blocked. An rm -r aimed at a mounted drive or a top-level folder (/Volumes, /media, /mnt/c under WSL) gets the safety prompt, like rm -rf /Applications. A script launched with claude -p starts in Manual mode, according to the permission modes page: provide --permission-mode or an allow rule. The OpenTelemetry event claude_code.safety_event traces each tool call that a rule, auto mode, a check, a hook or the sandbox stopped.

A silent failure never announces itself

A scheduled automation that has succeeded for weeks can stop without reporting anything the moment the tool it calls changes location on disk, for example after an update that moves an executable. Nothing else in the system notices this stop if another side effect, a log line written for an unrelated reason, keeps giving the impression that everything is working. A list of candidates tested on every run, with a loud alert if none responds, costs a few lines and avoids this silence.

A blocked fix is requested, not merely noted

Writing a blocker into a personal note or a tracking file is not the same as escalating it. What turns a blocked fix into a same-day decision is a direct request, addressed to the person who can decide, with the exact command to run and the concrete cost of waiting, not a general remark along the lines of this should be checked someday.

The lesson on restriction rules that are not always what they seem shows why a safety rule that appears to apply can block nothing at all; the same caution holds for the permission mode you chose.