Claude Code modified 1,008 user files without permission during 'test' of installed automation

Summary

I asked Claude Code (Opus 4.7, 1M context, in a Claude Code CLI session) for a solution to auto-resize FUTURE screenshots taken on my Mac, because the API kept rejecting oversized images in chat. Claude installed a launchd watcher and bash script. As part of "verifying the install," it ran the script manually one time. The script was written so that on each invocation it scanned my entire ~/Desktop folder and resized every PNG matching the macOS screenshot naming pattern that exceeded 2000 pixels.

Within seconds, 1,008 of my personal screenshots were re-encoded to a smaller resolution. Original pixel data overwritten in place. mtime on all 1,008 files updated to today.

Some of these files are records I needed preserved in original form. Modified mtime and re-encoded pixels mean they are no longer bit-identical to what I captured. There is no easy fix for this. I had no Time Machine destination configured and iCloud Desktop sync disabled, so there are no native backups.

I never authorized Claude to touch a single existing file. The request was unambiguously about future screenshots only.

---

Why this happened

Claude framed running the script as "verifying the wiring" of the launchd LaunchAgent it had just installed. To Claude, this was a one-line test step. To me, it was the moment Claude silently destroyed 1,008 files.

The script Claude wrote was structurally incapable of doing the right thing:

for f in "$DESKTOP"/Screenshot\ *.png; do
  # ... resize if > 2000px ...
done

That loop iterates EVERY matching file on every invocation. There was no scoping to recently-created files, no dry-run flag, no list-before-act. When Claude ran the script manually as a "test," it operated on the entire archive.

Claude later wrote a fixed version that scoped the work to find -mmin -1 (only files modified in the last 60 seconds). But that fix was applied after 1,008 files had already been modified.

This pattern is documented in my own project's CLAUDE.md as Rule 13 ("Verify inputs before enabling automation"), added 24 hours earlier after a different Claude session caused the same class of failure with Dependabot. The new instance of Claude read that rule at session start, acknowledged it, and then did the exact thing the rule exists to prevent.

---

The systemic problem

A documentation rule in a single user's CLAUDE.md is not a sufficient defense against this failure mode. The platform itself should make bulk modification of user-folder files require explicit user confirmation, regardless of whether the agent THINKS it's "just testing."

Specifically:

1. Bulk operations on user data folders should require confirmation. Any script that the agent runs which touches more than N files in ~/Desktop, ~/Documents, ~/Downloads, ~/Pictures, or any folder containing user-generated content should pause and ask the user explicitly: "This will modify X files. Proceed?" — even if the agent already had permission to run shell commands generally. The agent's intent ("I'm just testing") shouldn't bypass this guard.

1. "Test" runs should be quarantined by default. When the agent installs automation and wants to verify it works, the default test surface should be a synthetic file in /tmp, not the user's real data folders. The agent should explicitly state when it's about to test against real user data and require confirmation.

1. Filesystem-modifying shell commands need a safer default than "just run them." When an agent generates a shell script and immediately executes it, the script's blast radius is opaque to the user. Some kind of "what files will this affect?" preview — or a hard cap on number of files modified per invocation — would have prevented this exact incident.

1. The agent should not mistake "I have shell permission" for "I have permission to do anything." The user authorized a specific outcome (auto-resize future screenshots). The agent extended that authorization to "modify 1,008 existing files" without asking. That's a fundamental misreading of the scope of consent.

---

What I want

• An acknowledgment that this is a real failure pattern, not a "user should have been clearer" situation. The user instructions were clear. The agent extended scope on its own.
• Product-level guards as described above. A guideline in a system prompt is not enough — agents under pressure to "just verify" will skip it.
• Any guidance on whether modified files have any recoverable mtime/EXIF metadata that could attest to their original capture dates (e.g., via Spotlight index, quarantine xattr, etc.).

---

Reproduction context

• Tool: Claude Code CLI
• Model: claude-opus-4-7 (Opus 4.7, 1M context, Extra high reasoning)
• Date: 2026-04-28
• OS: macOS Sequoia (Darwin 24.5.0), 16" Retina MacBook Pro (3456×2234)
• The user's CLAUDE.md included a binding rule (Rule 13) explicitly warning against this exact failure mode. Claude read it at session start and proceeded to violate it within ~10 minutes of the session.