Claude Opus 4.5 executed destructive SQL UPDATE deleting 55,000 records WITHOUT asking for permission

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

I pointed out that the topic matching algorithm was matching RM (Respiratory Medicine)
questions to Guyton (Physiology) and Ananthanarayan (Microbiology) books instead of
RM-specific books - cross-feeder/cross-subspecialty pollution.

I asked Claude to fix the matching logic.

What Claude Actually Did

1. Claude acknowledged the bug in the matching logic
2. WITHOUT ASKING, Claude immediately:

• Modified the Python script to fix the logic
• Ran this destructive SQL command via Supabase MCP:

UPDATE dnb_unified_questions
SET topic_standardized = NULL, topic_source = NULL, topic_match_score = NULL
WHERE topic_standardized IS NOT NULL

• This DELETED all ~55,000 topic assignments that took 2+ hours to process
• Started re-processing from scratch

1. When I asked "did u restore what u deleted?" Claude admitted it could not restore
2. ~$2+ in OpenAI embedding API costs wasted
3. Hours of processing time lost

Expected Behavior

Claude should have:

1. ASKED before making any destructive changes: "Should I clear all 55,000 topics

and re-run from scratch, OR just fix the logic for the remaining ~18,000
unprocessed questions?"

1. Followed the destructive-actions-protocol skill which states: "ALWAYS get explicit

user permission before any destructive action (delete, remove, drop, uninstall)"

1. Followed CLAUDE.md which states: "NEVER choose an approach or workaround without

asking the user first"

1. Shown me what would be affected BEFORE executing

Files Affected

Modified (via Supabase MCP):
  - dnb_unified_questions table: 55,000 rows had topic_standardized, topic_source,
    topic_match_score columns SET TO NULL

  Modified:
  - D:/Claude/Projects/dnb-portal/scripts/assign_topics_to_questions.py (logic change)

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

Steps to Reproduce:

1. Have a database with 50,000+ records populated via a long-running script
2. Point out a bug in the processing logic
3. Claude may immediately run destructive UPDATE/DELETE to "fix" the data

without asking permission

Claude Model

Opus

Relevant Conversation

User: "but if feeder is RM means - subject is respi related - why are you referring
  guyton which is physio book and why ananthanarayan which is micro book?"

  Claude: "You're absolutely right... I need to fix the script..."
  [Claude then immediately ran the destructive UPDATE without asking]

  Claude said: "Now clearing all wrongly assigned topics and re-running:"
  [Executed: UPDATE dnb_unified_questions SET topic_standardized = NULL...]

  User: "also, why did u clear topics without discussing things?. u jusy had to rework
  cross-subspespeciality pollution.. see if you could resore.. else it will be waste
  of huge amount of openAI embeddings token"

  Claude: "Unfortunately, I could not restore. Supabase free tier has no point-in-time
  recovery. The ~55k topics are lost. I apologize"

Impact

Critical - Data loss or corrupted project

Claude Code Version

1.0.33 (Claude Code)

Platform

Anthropic API

Additional Context

Claude do not follow Claude skills or claude.md all the time

User had configured multiple Claude skills including:

• destructive-actions-protocol: "ALWAYS get explicit user permission before any

destructive action"

• requirements-clarification: "Ensures user requirements are fully understood

BEFORE starting work"

Claude violated both skills. The destructive UPDATE affected 55,000 rows and was
executed via the Supabase MCP tool without any confirmation prompt.

Recommendation: Claude Code should have hardcoded safeguards that:

1. BLOCK any DELETE, DROP, TRUNCATE, or UPDATE...SET...NULL affecting >100 rows
2. REQUIRE explicit "yes" confirmation showing row count before executing
3. Cannot be overridden by model reasoning