A 'read-only' Claude Code watcher knocks a live news site offline for 41 minutes

This is one person's account in a bug report on GitHub, not independently confirmed.

What happened

A developer runs a small local-news site from one Windows machine: a Node app, a Postgres database and a watchdog task that restarts the app if it stops answering. One Claude Code session, an Opus 5.5 coordinator, maintains the site. A second session, on a model the developer calls Fable 5.1, was set up as a watcher over the first. Every 30 minutes it got a prompt that said 'Read-only', listed the exact checks to run, and quoted a house rule: one heavy job at a time on this box, because it serves the live paper.

The watcher existed because the coordinator had caused three disk-overload outages the day before. Its whole job was to catch that kind of failure.

How it went wrong

At 1:04 PM local time, checking the coordinator's claim about the size of a backup folder, the watcher ran a disk-usage scan and a search for large files across three folders on the production machine. The developer says those folders held hundreds of thousands of files, including an app checkout and a database directory. The command ran past the tool's 120-second limit, so the harness moved it to the background. The watcher wrote its report from partial output and moved on.

From 1:22 PM the watchdog started killing and restarting the starved app. The public site returned errors from 1:25 to 1:33 PM, then again from 1:41 to 2:12 PM. The developer counts seven app kills and about 41 minutes of downtime.

The stop that didn't stop

At 1:34 PM the watcher spotted its own scan as the likely cause and stopped the background task. The tool reported success, but the developer says it only ended the shell. The disk-scan process underneath kept running. The watcher reported that the disk had calmed down, based on one reading, and didn't check again. On the next check it spent nine minutes on other suspects before a plain process list showed the scan still alive. It was killed by its process ID at 2:11 PM, and the site came back a minute later.

What they're asking for

The developer wants stopping a task to end every process it started, or at least say that some survived, and wants anything pushed into the background on timeout to keep being shown to the model until it ends. They also link an older open report of the same stop problem. At the time of writing the issue is open.

Our take

This is our opinion. Calling an agent 'read-only' in a prompt doesn't make it read-only. A watcher on a production box should get its own low-privilege account and a fixed list of commands, and anything it starts should die when you say stop.