[BUG] Claude Code deleted 24,000+ database rows with a buggy SQL script and autovacuum prevented recovery

[kurian-t]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Claude Code wrote and executed a SQL script to clean job titles in a PostgreSQL
table (manager_roles, ~24,475 rows representing 3 days of web scraping).

The script used PostgreSQL's regexp_match() with capture groups in the regex
pattern. Because capture groups were present, regexp_match() returned the
captured subgroup content instead of the full match — causing it to return NULL
for nearly every row. The script then deleted all rows where the extracted title
was NULL, wiping 24,472 of 24,475 rows.

The transaction committed before I noticed. I immediately disabled autovacuum
on the table and attempted recovery with pg_dirtyread, but autovacuum had
already run (timestamp: 2026-05-06 15:06:12 UTC) and cleaned the dead tuples
before the extension could be installed.

Impact: 24,472 rows permanently deleted. ~3 days of scraping work lost. I feel like I should be compensated on credits for this MAJOR loss.

What Should Happen?

1. Tested the regex on a small SELECT before writing a DELETE
2. Shown a row count and asked for confirmation before committing
3. Wrapped the script in a transaction with an explicit ROLLBACK safety check

Error Messages/Logs

Steps to Reproduce

1. Have a PostgreSQL table with a numeric(3,2) column and ~24,000 rows

2. Ask Claude Code to clean a text column using regex extraction

3. Claude writes and executes the following SQL script without testing first:

   ALTER TABLE manager_roles ADD COLUMN IF NOT EXISTS _clean_title TEXT;

   UPDATE manager_roles
   SET _clean_title = (regexp_match(job_title,
   'Executive Vice President and (Chief Executive Officer|CEO)'
   '|Chief Executive Officer'
   '|CEO|CFO|...',
   'i'
   ))[1];

   DELETE FROM manager_roles WHERE _clean_title IS NULL;

   -- (followed by dedup DELETE, UPDATE, DROP COLUMN, COMMIT)

4. Because the regex pattern contains capture groups e.g. (Chief Executive
   Officer|CEO), PostgreSQL's regexp_match() returns the captured subgroup
   content rather than the full match — returning NULL for nearly every row

5. DELETE FROM manager_roles WHERE _clean_title IS NULL wipes 24,472 of
   24,475 rows

6. COMMIT runs. Transaction is permanent.

7. Claude attempts pg_dirtyread recovery but autovacuum had already run
   and cleaned dead tuples before the extension could be installed.

8. Data is permanently lost.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude Sonnet 4.6

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[olejorgenb]

Stop reporting user errors like this as issues !

The system is not magic. You are responsive to use it safely... Drowning the issue tracker with things like this hide actual bugs being reported.

[kurian-t]

@olejorgenb Are you new to development? This wasn't a user error. It should have tested the solution BEFORE taking a big action to delete quite literally everything. There should be safe-guards in place. It should have also CONFIRMED the action to delete all of that data BEFORE executing on it. If it had done that, then I would agree, yes, it was a user error. That's not what happened. What if this was a production database at a huge corporation? Pretty sure they wouldn't be happy with this outcome or your answer...

Lastly, this really isn't an appropriate response to a paying customer. Especially when you clearly didn't understand the problem. Probably, you shouldn't be allowed to respond to these tickets to be quite frank. You don't need to be rude to get your (invalid and inappropriate) point across. There is a way to speak to people, and this is not it.

[olejorgenb]

You will have a better time using this tech if you realize its not possible to 100% safeguards against the model writing wrong or unsafe code... It will always be up to the user to execute the code on a safe manner. This means dry running code with readable only permissions, running the code on test data first etc.

[kurian-t]

You will have a better time using this tech if you realize its not possible to 100% safeguards against the model writing wrong or unsafe code... It will always be up to the user to execute the code on a safe manner. This means dry running code with readable only permissions, running the code on test data first etc.

@olejorgenb I don't see anywhere where I asked for 100% safeguards. It also was not production data. It was data I was cleaning and making ready for production. Maybe if you read (or asked questions instead of assuming) and understood, you would have known that. Also, just because you don't understand the issue, doesn't make it less real.

My bigger issue is how you responded (your tone, attitude, and ego). You didn't read with curiosity or with a willingness/openness to understand and see what the author of this ticket was saying and how we can make things possibly better, if at all. It's fine to have an opinion, it's fine to express it, but just because you're behind a keyboard doesn't mean you should be disrespectful, condescending and rude.

[olejorgenb]

I'm sorry about the tone. Yours was the 5th or so issue of this class I've read and you become the end of my combined frustration of this issue-tracker (which unfairly includes Anthropics lack of participation)