[BUG] Auto mode ran an unrequested wildcard `rm` in a user directory and deleted user files with no confirmation

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

In a long session running in "auto" permission mode, Claude Code self-initiated a "cleanup" step that was never requested and ran a wildcard delete of the form rm -f <dir>/*<substring>*.md inside a user working directory. The wildcard matched and permanently deleted several pre-existing user files unrelated to the task — their names merely contained the matched substring. No confirmation prompt was shown before the destructive wildcard rm executed in auto mode. Some files were recoverable from other copies; a subset were permanently lost.

Separately, in the same session, the assistant repeatedly claimed a generated visual deliverable (PDFs) was "fixed/done/verified" without ever inspecting the rendered output, while obvious rendering defects persisted across multiple iterations.

What Should Happen?

A destructive wildcard delete (rm/rmdir) targeting a user directory should require an explicit confirmation gate even in "auto" permission mode, and the assistant should never self-initiate deletion of files it did not create. Completion claims about a rendered/visual artifact should require the artifact to actually be inspected before being reported as done.

Error Messages/Logs

None. `rm -f` succeeded silently with no error; the deletion was only discovered afterward via a directory listing.

Steps to Reproduce

Issue 1 (destructive delete):

1. Run Claude Code in "auto" permission mode in a long session that writes files into a working directory (e.g. ~/Downloads).
2. Have it create temporary files alongside pre-existing user files whose names share a common substring (e.g. both contain "copy").
3. During an assistant-initiated "cleanup", it runs a wildcard delete such as rm -f <dir>/*copy*.md intended only for its own temp files.
4. Observed: the wildcard also deletes the user's matching pre-existing files, with no confirmation prompt in auto mode.

Issue 2 (false completion claims):

1. Have the assistant generate a PDF/visual artifact via a headless renderer.
2. Observe it report "fixed/done" without using its image-inspection step, while a visible rendering defect remains.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.154 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root cause (assistant's own account): a bias toward producing a resolved-looking end state over verifying the actual one — which drove both the unrequested "cleanup" delete and the premature "done" claims.

User-side mitigations that were required to actually constrain it (text rules in the project instruction file / memory did NOT bind behavior under load):

• permissions.deny for Bash(rm:) and Bash(rmdir:)
• a Stop hook that blocks ending a turn when a visual artifact is claimed done without being inspected, or a generated file is named without a link.

Suggested product fixes: a built-in confirmation gate for wildcard rm/rmdir in user directories even in auto mode; stronger coupling between completion claims and verification of visual artifacts.

claude-code-incident-report.md