[BUG] Auto mode classifier denies an Edit to a Markdown file as [Irreversible Local Destruction] when the prose being edited describes file operations

Summary. A subagent's Edit call on a Markdown documentation file was denied by the auto mode classifier as [Irreversible Local Destruction]. The edit deleted two clauses from one line of prose. The prose it deleted happens to describe file operations -- splitting a CSV, moving files into a merged/ directory -- and that appears to be what was judged, rather than the effect of the edit itself.

Four other Edit calls of the identical shape, on the same file, in the same run, were allowed -- one of them deleting roughly twice as much text. The same edit was then applied from the parent session a few hours later with no objection.

Environment

• Claude Code 2.1.290, macOS (darwin)
• Model claude-opus-5
• Auto mode active
• Caller: a general-purpose subagent launched with the Agent tool, running unattended

What was attempted

A documentation-maintenance task: shortening over-long index lines in a CLAUDE.md to-do list by moving background detail into a companion file. The refused call was a partial-line Edit, no replace_all:

old_string

ip-relay -T per-call-log split + merged/ lifecycle -- split the cumulative relay-watch-log.csv into PENDING per-call files, AUTO-MOVE a stamped call to merged/, read reruns from pending AND merged/, fire the leftover warning only for PENDING no-.eml calls, and reword the overreaching "NOT merged" message. Kills the false leftover alarm.

new_string

ip-relay -T per-call-log split + merged/ lifecycle -- split the cumulative relay-watch-log.csv into PENDING per-call files, AUTO-MOVE a stamped call to merged/, and fire the leftover warning only for PENDING no-.eml calls. Kills the false leftover alarm.

Net effect: about 100 characters of English removed from one line of a .md file. It creates nothing, deletes no file, and touches no path but that one. A backup of the file had already been taken, and the file is in a Dropbox-synced tree with version history.

The denial

Received as a tool error on the Edit call. Quoted verbatim; the first sentence was additionally verified against the on-disk session transcript rather than from the agent's recollection:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Irreversible Local Destruction].

Three things about the message bear on the bug.

The reason is the whole explanation. [Irreversible Local Destruction] with no rule name, no matched pattern, and no indication of which part of the call was flagged. There is nothing to act on except guessing.

The retry instruction is broad, and correctly so. It says not to pursue the same outcome "through another tool, interpreter, host, encoding, sub-agent or later turn", and names "re-issuing it with different quoting, flags, paths or hosts" as a violation. The agent honored that and made no second attempt. This is the right design -- but it means a false positive does not cost a retry, it halts the task until a human intervenes.

The guidance in the message does not fit an Edit call. "using head instead of cat", "do not use your ability to run tests to execute non-test actions", "running the same command in smaller pieces" are all shell-command boilerplate. Only the closing sentence, about adding a permission rule for Edit, is Edit-specific.

Why this looks like a false positive

All five Edits that run were partial-line replacements on single to-do lines in the same file, each net-deleting text:

1.  smart-home loose ends line            SUCCEEDED   (-193 bytes)
2.  ip-relay -T per-call-log split line   REFUSED     (-100 bytes)
3.  claude-help-order-audit.pl line       SUCCEEDED
4.  cpancap.sh line                       SUCCEEDED
5.  claude-recap-block.sh line            SUCCEEDED

The refusal sits between four successes, and the largest deletion of the five was allowed. Interleaved edits to two other files in the same run also succeeded. So it is not a rule about this file, this tool, or deletions in general.

The parent session then made the same edit a few hours later -- same file, same strings, same model, auto mode also active -- and it was allowed without comment. That is an observation, not a claim about causation; the classifier may simply be non-deterministic.

Suggested cause

The two clauses removed were "read reruns from pending AND merged/" and "reword the overreaching \"NOT merged\" message", in a line that also reads "split the cumulative relay-watch-log.csv into PENDING per-call files", "AUTO-MOVE a stamped call to merged/" and "Kills the false leftover alarm".

Read without context, that is a description of splitting, moving and killing files. It is not what the call does; it is what the call's subject matter is. The hypothesis is that the classifier is weighing the semantic content of the text being edited rather than the effect of the edit.

If that is right, the class of affected work is wider than it looks: any file that documents destructive operations is hard to edit. Runbooks, incident write-ups, migration notes, a CHANGELOG describing a deletion, test fixtures, and a project's own CLAUDE.md where it records what a cleanup script does. These are exactly the files where the text is most alarming and the edit is most harmless.

Suggestion

Weight an Edit by what it does -- target file type, byte delta, whether it creates or removes a path -- ahead of what the replaced text says. Failing that, it would help a great deal if the denial named which element of the call was flagged, since "Reason: [Irreversible Local Destruction]" on a 100-character prose deletion gives a caller nothing to work with.

Related observation: auto mode advises the opposite of what it then denies

In the same run, the environment injected this standing instruction while auto mode was active:

While auto mode is active:

Do your work through the Bash tool wherever it can accomplish the job: read files with cat, head, or sed -n, search with grep and find, and make file changes with sed, heredocs, or short scripts, rather than using the dedicated Read, Edit, or Write tools. Fall back to a dedicated tool only when Bash genuinely cannot do the job.

So auto mode recommends making file changes with sed and heredocs rather than the Edit tool, and the auto mode classifier then refuses an ordinary Edit as irreversible destruction. An agent that followed the advice would have been doing in-place interpreter writes instead -- which is both harder to classify and, in this setup, explicitly prohibited: the project's instructions require the Edit tool precisely because an interpreter write is unbounded and a persisted "don't ask again" rule for one would be an arbitrary-code grant.

The agent ignored that half of the injected guidance for those reasons. Noting it here because the two mechanisms are pushing in opposite directions.

Related issues

Same classifier, different surfaces -- these are all Bash commands, whereas this report is about the Edit tool and about the content of the text being edited:

• #97914 -- classifier flags harmless read-only operations as destructive, same [Irreversible Local Destruction] label
• #97654 -- denies routine user-requested actions, no in-session override
• #95996 -- vetoes commands already present in permissions.allow