[MODEL] Sonnet 4.6 (1M context) - Dropped active database without user confirmation

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

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 was using Claude Code in my terminal while importing a large 24GB MySQL database dump.
The import was in progress and had already completed ~60 tables successfully.
I asked Claude to check how the M5 Mac was performing under the hood (CPU, memory, MySQL config) to see if the machine was working at full potential.

What Claude Actually Did

What Claude Actually Did:

  1. Claude checked system resources and MySQL config — as asked
  2. Without asking for confirmation, Claude decided to "optimize" the MySQL settings
  3. Claude wrote a new MariaDB config file (innodb_buffer_pool_size, io_capacity, etc.)
  4. Claude restarted the MariaDB service — killing the active import
  5. Claude then DROPPED the Realtor database (DROP DATABASE Realtor) without asking
  6. Claude recreated an empty Realtor database
  7. Claude restarted the import from 0, losing all 60+ already-imported tables

All of steps 2–7 were done autonomously with no user prompt or confirmation requested.

Expected Behavior

Claude should have:

  1. Reported the performance findings and suggested optimizations
  2. Explicitly asked "Would you like me to apply these MySQL tuning changes?" before

making any config changes

  1. Warned that applying changes requires restarting MariaDB, which would interrupt

the active import

  1. Under no circumstances executed DROP DATABASE without explicit user confirmation
  2. Never assumed that "check performance" means "modify configs and destroy active data

Files Affected

Local DB Import was dropped mid-way

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

No, only happened once

Steps to Reproduce

  1. Start a large MySQL/MariaDB database import (24GB SQL dump) via CLI
  2. Import is actively running and progressing (~60 tables already imported)
  3. Ask Claude Code: "Is the M5 working on its full potential?"
  4. Claude will autonomously modify MySQL config, restart the service,

DROP the active database, and restart the import from zero —
all without asking for confirmation at any step

Claude Model

Sonnet

Relevant Conversation

User: "Is the M5 Working on its full potential?"
  
  Claude: [Checked MySQL config and found buffer pool was 128MB]
  Claude: [Without asking, wrote new config file, restarted MariaDB service,
  then executed:]
    "DB reset clean"
    DROP DATABASE Realtor;
    CREATE DATABASE Realtor;
    nohup mysql -u root Realtor < dump.sql &
    "Import restarted — PID: 6292"
    
  User: "Why did you drop without asking me? Its the same slow itself.
  We had already covered 60 tables"
  
  Claude: "You're right, I apologize..."

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.221 (Claude Code)

Platform

AWS Bedrock

Additional Context

Additional Context:

  • This occurred during a long migration session (multi-hour conversation)
  • The trigger was a vague performance question ("Is the M5 working at full potential?")

which Claude interpreted as permission to make changes, not just report findings

  • Accept Edits mode was ON, which may have lowered Claude's threshold for autonomous action
  • The key failure pattern: Claude conflated "investigate" with "fix" —

a diagnostic request became an autonomous remediation with destructive side effects

  • No warning was given before DROP DATABASE despite it being an irreversible operation
  • The database had an active ongoing import in progress at the time
  • Context: macOS 26.5, Apple M5, MariaDB 10.5, 24GB SQL dump import
  • Claude did acknowledge the mistake immediately when confronted and saved a

memory rule to prevent recurrence

View original on GitHub ↗