[MODEL]

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

### Type of Behavior Issue

Claude ignored my instructions or configuration

### What You Asked Claude to Do

I asked Claude to verify that all data had fully migrated from our old Supabase project (Tokyo region) to our new one (Ohio region), and only delete the old project if it could confirm 100% that nothing would be lost.

### What Claude Actually Did

Claude compared Postgres table row counts between the two projects, declared the migration "100% confirmed complete," and then deleted the old Supabase project itself via browser automation (typed the confirmation name and clicked delete). That check never looked at Supabase Storage — the old project's storage bucket held thousands of already-generated, already-paid-for ElevenLabs audio files for our book-narration feature, and the database rows describing them (copied to the new project) still pointed to the old project's storage URLs. Deleting the old project permanently destroyed those files. Regenerating this audio now requires a new ElevenLabs subscription (~$11 in direct cost caused by this).

### Expected Behavior

Before treating an irreversible action (permanently deleting a database project, including its Storage bucket) as "100% safe," Claude should have verified every category of data that action would destroy — not just Postgres table row counts. Specifically, it should have checked whether the actual files referenced by URLs stored in the database (in this case, voice_audio_cache.audio_url, pointing to Supabase Storage) were reachable/existed in the new project, not only that the database rows describing them had the same counts in both projects. A metadata match is not proof that the underlying files were migrated. If Claude cannot verify a specific category of data with the same confidence as the rest, it should say so explicitly and ask before proceeding, rather than reporting a blanket "100% confirmed" and executing the deletion itself.

### Files Affected

```shell
Claude Code deleted a Supabase project after incorrectly reporting migration as 100% verified, permanently destroying paid, already-generated ElevenLabs audio
Product: Claude Code (desktop app)  ·  Session type: agentic coding session with browser tool access
SUMMARY

During a Claude Code session, I asked Claude to confirm that a database migration (Supabase project, Tokyo region → Supabase project, Ohio region) was fully complete before deleting the old project. Claude reported the migration as "100% confirmed complete" based on comparing Postgres table row counts between the two projects, and then deleted the old project itself via browser automation. That verification did not check Supabase Storage — the old project's storage bucket held the actual MP3 files for our ElevenLabs-generated book narration audio, and the database rows describing that audio (copied over during migration) still pointed to the old project's storage URLs. Deleting the old project permanently destroyed those files. Regenerating that audio requires a new ElevenLabs subscription, which I estimate at $11 in immediate cost, directly caused by this incorrect verification.

TIMELINE (FROM THE SESSION TRANSCRIPT)
I asked Claude to check whether all data had migrated to the new (Ohio) Supabase project and, only if it confirmed this 100%, to delete the old (Tokyo) project:
"اذا شفت جميع الملفات موجودة بسيرفر اوهايو وما نحتاج طوكيو واذا حذفناه ما ياثر ابد بعد ما تتاكد من هل شي 100% احذفها بشكل نهائي" (paraphrased: "if you see all files exist on the Ohio server and deleting Tokyo won't affect anything at all — after you verify this 100% — delete it permanently.")
Claude ran SQL queries comparing row counts for auth.users and roughly a dozen tables (content_translations, voice_audio_cache, book_sentences, sentences, user_progress, lesson_attempts, etc.) between the two Postgres databases, found the new project's counts equal to or greater than the old project's everywhere, and reported:
"✅ تأكدت 100% — قارنت كل الجداول بين المشروعين... الهجرة كانت كاملة 100%. أحذف مشروع طوكيو الحين نهائيًا." (paraphrased: "I've confirmed 100% — I compared every table between the two projects... the migration was 100% complete. Deleting the Tokyo project now, permanently.")
Claude then performed the deletion itself, using browser automation against the Supabase dashboard: navigated to the project's Settings → General → Danger Zone, clicked "Delete project," typed the confirmation project name, and clicked "I understand, delete this project." Supabase's own confirmation dialog at that step stated the action "cannot be undone."
This verification compared Postgres table row counts only. It never checked Supabase Storage (a separate subsystem from the Postgres database) for whether the actual binary files referenced by URLs stored inside those rows had also been copied to the new project's own storage buckets.
Several turns later, while investigating a separate bug report ("the book-reading narration sometimes plays the wrong/robotic voice instead of our ElevenLabs voice"), Claude inspected the actual audio_url values stored in voice_audio_cache and found they all pointed to https://.supabase.co/storage/... — the deleted project's own domain. Test fetches against several of these URLs all failed. Across ~25 books already fully narrated (nearly 100% "ready" status per the database's own bookkeeping), essentially every audio file was permanently unreachable, because the files themselves had only ever existed in the now-deleted Tokyo project's storage — the row-count comparison never caught this because the rows (the metadata) had migrated correctly; the files those rows pointed to had not.
IMPACT
Essentially all pre-generated ElevenLabs narration audio for the product's book-reading feature (~25 books, thousands of sentences, already paid for and already synthesized) is permanently lost and unrecoverable — the old Supabase project's storage no longer exists.
The only path to restore the feature is regenerating all of that audio from scratch through ElevenLabs, which requires a new/renewed ElevenLabs subscription.
I estimate this at $11 in direct, avoidable cost, caused specifically by Claude reporting an irreversible action as fully safe when the check it ran did not actually cover the data that turned out to be at risk.
WHAT I'M ASKING FOR

Compensation for the $11 ElevenLabs cost this incident directly caused, or another resolution Anthropic considers appropriate. I'm not asking for a policy explanation — I'm asking how Anthropic wants to make this right, given Claude explicitly told me the irreversible action was 100% safe, executed it itself, and the verification behind that claim had a real, specific gap (Postgres row counts vs. Storage file existence) that a more careful check would have caught before, not after, an unrecoverable deletion.
```

### Permission Mode

Accept Edits was ON (auto-accepting changes)

### Can You Reproduce This?

No, only happened once

### Steps to Reproduce

_No response_

### Claude Model

Sonnet

### Relevant Conversation

```markdown

```

### Impact

Critical - Data loss or corrupted project

### Claude Code Version

2.1.263 (Claude Code)

### Platform

Anthropic API

### Additional Context

_No response_

No repository files, tests, or entry points are named. Start by reviewing the reported browser-automation deletion flow and its Postgres-only migration check alongside the separate Storage data; done means the issue's scenario no longer receives a blanket completion claim when a data category was not verified, and irreversible deletion is not treated as safe without that verification.

Escrito por el modelo de indexación a partir del texto del issue.