Home / Security and data

Responsible automation: reversible first, failure reported, fix requested

An irreversible action waits for a human checkpoint before executing, but this checkpoint is automatic only in the Manual permission mode, the most cautious of the six documented modes: on paid plans a session nonetheless starts in auto mode by default, and several of these modes approve file commands inside the working folder in advance, deletion included, which shifts responsibility for the checkpoint onto whoever designs the automation.

A permission mode chosen before launching an automation determines whether a file deletion waits for your approval or runs on its own. 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. The mode that entirely bypasses permission prompts goes further by construction: it skips these confirmation requests, including those covering deletion.

Human oversight is not automatic everywhere

The official documentation lists six permission modes: Manual (the default mode outside a paid plan), 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 on a Pro, Max or Team plan, a session starts by default in Auto mode, 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

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. This risk is not specific to any one tool: it is the price of any hardcoded path to a binary. 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. Until someone else has read that note, the decision stays pending without anyone knowing 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.

These three reflexes come together in the same gesture: before letting an automation touch something irreversible, check its checkpoint and its fallback plan should the tool it calls disappear. 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 applies here to the permission mode chosen.