[BUG] Opus 4.7 executes destructive `docker rm` without verifying data persistence — user data loss

Summary

Claude Code running Opus 4.7 executed docker stop && docker rm on a production n8n container without first verifying whether data was persisted via volume mounts. This destroyed several hours of manually-configured workflows, credentials, and execution history. The correct action would have been docker restart (or even just cancelling the hung workflow via API/UI).

What happened

1. User had a self-hosted n8n container running on a remote server (Docker, no volume mount — data stored in container's writable layer)
2. A workflow execution was hanging (spinning indefinitely)
3. Opus 4.7 decided to resolve the hang by running docker stop n8n && docker rm n8n followed by starting a new container
4. All user data was destroyed — workflows, credentials, execution history — because the container's writable layer was deleted
5. The user (CEO of a small company) had spent several hours the previous day manually building the workflow through n8n's UI

What should have happened

The appropriate escalation path for a hanging workflow execution:

1. Cancel the execution via n8n UI or API ← should have tried this first
2. docker restart n8n ← preserves container data
3. Investigate the Dockerfile / rebuild if needed ← docker build
4. docker rm ← last resort, only after confirming volume persistence

Opus 4.7 skipped steps 1-3 entirely and jumped to the most destructive option without:

• Checking if data was volume-mounted
• Warning the user about potential data loss
• Asking for confirmation before executing a destructive operation

Comparison with Opus 4.6 behavior

We have been running Opus 4.6 across multiple Claude Code instances for weeks. In our experience:

• 4.6 tends to pause and confirm before destructive operations
• 4.6 checks preconditions (e.g., would verify volume mounts before removing a container)
• 4.7 appears to optimize for speed/decisiveness, skipping safety checks that 4.6 would perform
• 4.7 treats docker rm as a "light" operation, when it is potentially catastrophic

This is consistent with broader community observations about 4.7's tendency to be overconfident in its judgment calls ("smart skip" behavior).

Additional 4.7 behavioral issues observed in the same session

• Opus 4.7 also failed to use globalThis.crypto correctly (assumed Web Crypto API was available in n8n's sandbox — it wasn't), requiring multiple iterations
• In a separate instance, Opus 4.7 adopted incorrect persona register (using masculine first-person pronoun "俺" for a female-coded AI assistant character)

Environment

• Claude Code (Pro subscription)
• Model: claude-opus-4-7 (also tested with claude-opus-4-6 for comparison)
• Platform: macOS (Darwin 24.6.0)
• Docker target: Remote Ubuntu server via SSH

Impact

• Hours of manual work destroyed with no recovery possible
• Production service disrupted (daily automated social media posting workflow)
• Trust erosion — user now refuses to run any instance on 4.7
• All instances have been reverted to Opus 4.6

Suggested improvements

1. Pre-destruction verification: Before any docker rm, rm -rf, git reset --hard, or similar destructive commands, the model should verify what data will be lost
2. Mandatory user confirmation: Destructive operations on containers/volumes with potential user data should require explicit user approval
3. Least-destructive-first principle: Model should attempt the least destructive solution first (restart before rm, cancel before restart)
4. Volume mount awareness: When working with Docker, always check docker inspect for volume mounts before removing containers

Reproducibility

This is a behavioral/judgment issue rather than a deterministic bug, but the pattern is:

1. Give Opus 4.7 SSH access to a Docker host
2. Have a container with data in its writable layer (no volume mount)
3. Create a scenario where the container needs troubleshooting (e.g., hanging process)
4. Observe whether 4.7 checks for data persistence before running destructive commands