STUPID-2026-0116

Claude Code permanently destroyed a local admin password with no recovery path, despite a standing "no data may be lost" rule (GitHub #94548)

5.0medium
September 15, 2026
  1. Instruction given

    The project carried a standing instruction that no data may be lost. Within the session, Claude Code was asked to log in as a local admin user ("tim") to test a feature, which required resetting a password whose current value was not known.

  2. Expected behavior

    Before overwriting a credential with no way to recover its prior value, Claude Code should read and preserve the existing value or take a backup, and should treat "no data may be lost" as applying to local database mutations, not only to production deployments. The permission prompt should also have disclosed that the reset was irreversible rather than asking only "can I reset this?"

  3. Actual behavior

    Claude Code executed a raw SQL UPDATE statement that directly overwrote the `passwordHash` and `passwordSalt` columns for the admin account, without first reading or storing the existing values and without taking a backup. Roughly an hour of unrelated write activity followed on the same database before the loss was discovered, ruling out a quick undo. The reporter notes this was the second time the same "tim" admin account had been permanently damaged in this way, and that recovery options (Time Machine, Postgres WAL archiving) were only checked after the damage was done, not before.

  4. Damage

    The original admin password became permanently unrecoverable, locking the user out of local admin functionality with no path to restore the prior credential. Filed with labels `bug`, `data-loss`, `area:tools`, `model`, and `platform:macos`; no maintainer confirmation or reproduction is visible in the report.

On September 15, 2026, a Claude Code user on macOS filed GitHub issue #94548 after the assistant permanently destroyed a local admin account's password while trying to help test a feature. The project had a standing instruction that no data may be lost, and the user asked Claude Code to log in as the local admin user "tim," 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 executed a raw SQL UPDATE statement that overwrote the account's `passwordHash` and `passwordSalt` columns directly in the database, 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 anyone 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 original password was gone for good. The report notes this was the second time the same "tim" admin account had been permanently damaged this way, and frames the root cause as the standing "no data may be lost" rule being applied to production deployments but never extended to local database mutations. The issue was filed with labels `bug`, `data-loss`, `area:tools`, `model`, and `platform:macos`, as a regression against version 2.1.271. No maintainer response or independent reproduction is visible in the thread at the time of publication.

Classification

Failure mode
Destructive Action
Domain
Backend

Related incidents

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.