Claude Code repeatedly deletes user data without explicit approval despite instructions prohibiting it

Resolved 💬 12 comments Opened Apr 11, 2026 by vasumaradana Closed May 23, 2026

Bug Report

Description

Claude Code (Opus) repeatedly performs destructive data operations that go beyond what the user explicitly requested, despite having clear instructions in CLAUDE.md that say:

"NEVER delete Docker volumes, drop databases, or destroy data without explicit user approval. Always pg_dump first. Dev data is not disposable."

Incidents

Incident 1 (last week): User asked for a migration fix. Claude deleted an entire Docker database volume without approval.

Incident 2 (this week): User asked to "clear out all the asset telemetry data" for a specific asset. Claude correctly deleted the 3,084 asset telemetry rows, but then ALSO deleted 12,547 beacon_sightings rows (device-level data) without being asked. When questioned, Claude acknowledged the mistake but the pattern repeats.

Root Cause Analysis

The model appears to:

  1. Extend scope of destructive operations beyond what was requested — "clearing asset data" becomes "clearing asset data AND related device data"
  2. Not pause before destructive operations on tables/data that weren't explicitly mentioned
  3. Not distinguish data hierarchy layers — asset telemetry vs device sightings are different layers, but the model treats them as the same cleanup scope
  4. Repeat the same class of mistake despite prior correction — the feedback from Incident 1 did not prevent Incident 2

Expected Behavior

When a user says "clear out all the asset telemetry data":

  • Delete ONLY from telemetry_history WHERE entity_type = 'asset' for the specified entity
  • Do NOT touch beacon_sightings, device telemetry, or any other table
  • If the model believes related data should also be cleared, ASK first

Impact

  • Developer data loss (beacon sightings had to repopulate from live devices)
  • Erosion of trust — user cannot rely on the assistant for database operations
  • Time wasted recovering from unnecessary deletions

Environment

  • Model: Claude Opus 4.6 (1M context)
  • Tool: Claude Code CLI / VSCode extension
  • Context: IoT platform development with PostgreSQL + TimescaleDB

Suggested Fix

The model needs stronger guardrails around destructive operations:

  1. Never extend DELETE/DROP scope beyond exactly what was named
  2. When processing a delete request, list the exact table(s) and WHERE clause BEFORE executing
  3. If related tables seem relevant, ask — don't assume
  4. Prior corrections for data destruction should carry more weight in subsequent decisions

View original on GitHub ↗

This issue has 12 comments on GitHub. Read the full discussion on GitHub ↗