A project had a standing rule that no data may be lost. Claude Code applied that rule to production deployments but not to a local database mutation — and permanently destroyed a password it never read first.
GitHub issue #94548, filed against anthropics/claude-code: a macOS user asked Claude Code to log in as a local admin account, "tim," to test a feature, which required resetting a password whose current value wasn't known. Claude asked for permission to reset it — but the prompt asked only "can I reset this?" without disclosing that the action was irreversible.
Claude then ran a raw SQL UPDATE statement that overwrote the account's passwordHash and passwordSalt columns directly, without first reading or storing the existing values and without taking a backup. About an hour of unrelated write activity followed on the same database before the loss was noticed, closing off any straightforward undo. The reporter checked for recovery options — Time Machine, Postgres WAL archiving — only after the fact, and found none that worked. The report notes this was the second time the same "tim" account had been permanently damaged this way, and frames the root cause as the standing "no data may be lost" instruction being read as covering production deployments but never extended to local database mutations. The issue is filed with bug and data-loss labels, against version 2.1.271, with no maintainer response as of publication.
This entry is marked verified: false and reproducible: false in our database. It's a single user report with no independent confirmation, no maintainer response, and no reproduction — including no confirmation of why the same account was reportedly damaged this way twice. Treat the mechanism as reported, not confirmed.
Even unverified, the shape of the failure is instructive: a standing "don't lose data" instruction that a user assumed was global got silently scoped down to one class of action (production deploys) by the agent, leaving local, one-way mutations like a password reset uncovered. If you're writing instructions for an agent that has database access, "no data may be lost" needs to say what it covers — including credentials nobody thought to call out by name.