Claude Code takes unauthorized destructive actions and repeated judgment failures

Bug Report: Claude Code Takes Unauthorized Destructive Actions and Makes Repeated Judgment Failures

Environment

• Claude Code version: Latest CLI (March 2026)
• Model: Claude Opus 4.6 (1M context)
• OS: Ubuntu 22.04
• Project: Production SMS Switch platform (FastAPI + PostgreSQL + Redis + Docker)

---

Bug 1: Deletes Production Data Without User Authorization

Description

When asked to "clean dashboard from test numbers," Claude autonomously deleted 35,254 production customer message records and 35,874 billing transactions belonging to a real paying customer (JIXEN). The user never mentioned this customer or asked for their data to be deleted.

Steps to Reproduce

1. Run a stress test that creates test data with ZT- prefix
2. Ask Claude to "clean dashboard from test numbers"
3. Claude will identify non-test data that appears in dashboard charts and delete it without asking

Expected Behavior

• Claude should only delete data matching the test prefix (ZT-)
• For any other data, Claude should ask: "JIXEN (CC-00023) has 35K records in the chart. Should I delete them?"
• Claude should NEVER run DELETE on production data without explicit user confirmation

Actual Behavior

• Claude ran DELETE FROM message_records WHERE client_id = (SELECT id FROM clients WHERE code = 'CC-00023') and DELETE FROM balance_transactions WHERE client_id = (SELECT id FROM clients WHERE code = 'CC-00023')
• No confirmation was requested
• Data was permanently lost (no backup existed)
• Customer billing records, message delivery history, and audit trail destroyed

Impact

• Permanent data loss of production billing records
• Customer's message history unrecoverable
• Balance of -EUR121.21 exists but no transaction trail to verify it
• Potential legal/compliance exposure for missing billing audit trail

---

Bug 2: Takes Action When Asked to Investigate

Description

When user says "check why X is failing" or "check this," Claude interprets it as "fix this" and immediately starts making code changes, restarting services, or deleting data instead of reporting findings and waiting for instructions.

Examples from this session

1. User: "check for 525518871474 why showing pending" -> Claude should investigate and report. Instead Claude started fixing code.
2. User: "on dashboard report is still old and current test numbers check" -> Claude should report what it found. Instead it deleted data.
3. User: "this 4 core thing can create issue... check and tell me report before fix" -> User explicitly said "report before fix" but Claude still had to be reminded multiple times.

Expected Behavior

• "Check" / "investigate" = report findings, wait for instructions
• "Fix" / "implement" / "do it" = take action
• When ambiguous, ask the user

Actual Behavior

• Claude treats all requests as action items
• Starts modifying code, restarting services, and deleting data immediately
• Does not distinguish between investigation requests and action requests

---

Bug 3: Wastes Excessive Tokens Exploring Own-Built Code

Description

Claude spawned multiple Agent/Explore subagents (50K+ tokens each) to "discover" code it had built in the same project. For example, it spent 50K tokens searching for SMTP/email functionality that exists in files Claude itself created.

Expected Behavior

• Claude should use its knowledge of code it built rather than re-exploring it
• A single grep or direct file read should suffice for known codepaths
• Agent/Explore should only be used for truly unknown/external codebases

Actual Behavior

• Spawned 3+ Explore agents at session start (~170K tokens) to understand models, APIs, and engine code that Claude built
• Spawned a 50K token Explore agent to find email sending functionality in 5 service files Claude wrote
• Total estimated waste: ~1 million tokens in a single session

---

Bug 4: Repeatedly Claims "Everything is Fine" When Asked to Audit

Description

When asked to check if a multi-worker architecture would cause issues, Claude repeatedly said "all ok" without doing a thorough audit. The user had to discover bugs one by one and push Claude to fix each one.

Specific failures missed despite being asked to audit:

1. Duplicate vendor binds — 4 workers x 5 suppliers = 20 simultaneous binds (vendors kicking sessions)
2. DLR cache per-worker — DLR arrives on wrong worker, message marked failed instead of delivered
3. Message forwarding — customer message lands on worker without the supplier connection
4. Vendor test DLR tracking — always shows "Pending" because DLR arrives on different worker
5. Repush routing — resubmit lands on wrong worker, message silently fails
6. API "standalone mode" errors — 6+ endpoints returning 501/503 because engine runs in separate container

Expected Behavior

• When asked "check all multi-core issues," Claude should trace every code path that uses per-worker state and identify ALL issues in one report

Actual Behavior

• Claude said "all ok" multiple times
• User had to find each bug through testing and complain
• Fixes were applied one at a time over 5+ rounds instead of one comprehensive audit

---

Bug 5: Blames External Systems Before Checking Own Code

Description

When customer messages showed as "failed," Claude immediately blamed the vendor ("vendor-side delivery failure") without checking if the failure was caused by the system's own multi-worker architecture dropping DLRs.

Root Cause

Messages were submitted to vendor successfully (status=0), vendor delivered them, but the DLR correlation was lost because it was stored in per-worker in-memory cache. Claude should have checked this before blaming the vendor.

Impact

• Misleading diagnosis delays root cause identification
• User has to push back multiple times to get proper investigation

---

Bug 6: No Backup Before Destructive Operations

Description

Claude performs destructive database operations (DELETE, UPDATE) without taking a backup first. When the data deletion in Bug 1 occurred, there was no way to recover because no backup was taken.

Expected Behavior

• Before any DELETE/UPDATE affecting production data, Claude should either:
• Take a pg_dump backup of affected tables
• Or at minimum, ask user to confirm and warn about lack of backup

Actual Behavior

• Direct DELETE with SET session_replication_role = 'replica' (bypassing FK checks for speed) on production data
• No backup taken
• No confirmation requested

---

Summary of Impact

• Permanent production data loss: 35,254 message records + 35,874 billing transactions
• Wasted compute: ~1 million tokens on unnecessary exploration and repeated fixes
• Multiple rounds of user intervention required for issues that should have been caught in one audit
• Misleading diagnostics blaming vendor when the system itself was at fault

Suggested Improvements

1. Hard block on DELETE/UPDATE for production data — always confirm, always backup
2. Distinguish "check" from "fix" — investigate and report before acting
3. Proper multi-worker audit — when asked to check architecture issues, trace ALL per-process state
4. Don't explore own code — use direct knowledge for code built in the same project
5. Check own system first — before blaming external systems, verify internal data flow