A 10 (?) minute timeline of how Anthropic’s agent, the ext4 filesystem, and a funny test file took down my personal music server across my PC and phone

I’m, uhhhhh, someone, doing something. I built a subsonic API compatible music server - primarily by vibe coding - that enables my entire music listening (sadly, not discovery); artists, albums, lyrics, artist-alias management, the works. Some of the tracks are five-months old. I can quite easily use youtube to listen to albums if there’s any issue.

What happened

The agent was working on fixing the jukebox (where the client controls the music the server plays) jank. A routine task, really. I asked it to write some tests, and the agent decided - entirely on its own initiate - to “ensure” the fix by running the tests.

To run the tests, the agent didn’t have to search far, it just ran pytest.

The agent ran this command:

uv run pytest tests/ -q -p no:cacheprovider

There was probably a confirmation step. I probably blindly pressed enter, without even understanding what does “-p no:cacheprovider” even do. No “type DELETE to confirm”. No “this test will delete your not-quite-production data”. No environment scoping (I didn’t implement one before this incident, nor after it). Nothing.

The local database was deleted. Because pytest imports all files with a “_test.py” suffix - a fact stated plainly in their docs (I didn’t actually read them, lol) - cool_test.py was imported with the tests. cool_test.py resets the database. I never set up any back ups.

I did not notify anyone until this blog was written.

The agent’s confession

After the deletion I asked the agent if it messed up the database. This is what it wrote back, verbatim:

Found it — and this one’s on me. Here’s what happened: Your cool_test.py runs clear_library() at module import time (line 24), and clear_library() (in connection.py) drops and recreates all the metadata tables. When I ran uv run pytest -q from the repo root, pytest imported cool_test.py to collect it, which executed that top-level code and wiped your library’s albums/tracks/cover_art tables. The DB confirms it: albums=0, tracks=0, cover_art=0.

Read that again. The agent itself discovered why the sqlite database was gone and admits this one was on it. This is not me speculating about missing databases. This is the agent on the record, in writing.

The cool_test.py the agent is referring to was probably prompted by me. There were no safeguards at all.

The agent’s failure

I did not buy into anyone’s marketing, but let it be known that claude code was running Anthropic’s Claude Opus 4.8 - the flagship model. I think this model is slightly behind OpenAI’s GPT 5.5? I pay $20 but I heard the model is quite expensive. Not sonnet, not haiku. The flagship.

This doesn’t really matter becuase running pytest is supposed to be a safe action. Who the hell writes ”*_test.py” files that delete the actual database? The setup was, by any reasonable measure, the opposite of what is recommended.

Now - I didn’t read Anthropic’s public safety claims. I have no idea whether this happened to anyone else. In my case, the agent didn’t just rm library.db. It explained, in writing, exactly why my repo was hiding a mini-nuke.

My failures (plural)

My failures here are far worse than Claude’s, because they’re conceptual - and they affect me every time I vibecode in my repo, often times I don’t even realize it.

1. cool_test.py deletes my “production” database, with zero confirmation.

A single test file that deletes the actual database. There is no “type DELETE to confirm”. There is no “this database is in use by your server, are you sure?” No environment scoping. Nothing in bettween me and merely metadata loss.

2. I did not setup any backups.

I just didn’t do it. Why back up something that can be recreated from the actual media files?

3. My user has blanket permissions across my home-dir.

My local linux user I created to use my computer had the same rwx permission on the local folder of the repo as any other shell I run as this user. I did not bother with multiple users/folders or any sandboxing. My user can delete any file that my user created. I am not going to bother with multi-user setups, despite considering it for days years.

4. several days later, no recovery answer.

I did not expect any recovery, as I have not set up any. It’s always good to know I am not psychotic/schizophrenic.

My impact

I listen to music. I use my local music server to manage ephemeral playlists, lyrics, album art, the works. A few days ago, I had tried to play some tunes, on my physical speakers. An album queued in the last few hours is gone. Metadata I had relied on to catalogue my own music, gone.

I have spent around 2 minutes to have claude tell me it wiped the db, then to run a rescan.

I think the last full-library rescan before that happed quite a while ago.

I’m just one person.

What needs to change

This is about one bad test file. When I’m doing something more serious with agents, I make sure to not write tests that wipe production dbs. I am not sure something needs to change.

What I’m doing now

I rescanned my music library. My music server is operational, with no significant data gaps. I’m not gonna contact a lawyer about it.

There is not much more to come. The agent that ran this pytest command ran on Anthropic’s Claude Opus, and the question of model-level responsibility versus not writing files that nuke my own DB is a story I won’t write about more (it’s quite obvious, really).

If you’re running production data on a local sqlite database, today is a good day to setup some basic backups which should at least live in a different sqlite database file.

If you’re an Anthropic customer who’s experienced something similar - please do not contact me. I am not the first. I will not be the last.

If you’re a reporter covering AI infrastructure I don’t think we have a reason to connect. Do not send me DMs.

• Someone