anthropics / anthropics/claude-code

[BUG] Claude Code permanently destroyed a user's local admin password with no way to recover it, despite an existing standing instruction that no data may be lost.

Open
#94,548 0 comments 0 reactions 0 assignees View on GitHub
area:tools bug data-loss model platform:macos
Dominant language
Python
Stars
145k
Forks
23.1k
PR merge metrics
PR metrics pending

Description

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

What happened:
1. During a session, the assistant needed to log in as a local admin user (tim) to test a feature. It asked permission to reset the password, and the user granted it.
2. The assistant ran a raw SQL UPDATE overwriting passwordHash/passwordSalt directly, without first reading and preserving the existing values.
3. No backup of the local database existed from before the change — the project's existing backup tooling (scripts/backup-db.sh) is wired only into production deploy scripts, and the assistant did not apply that same discipline locally.
4. Roughly an hour of unrelated write activity (a large feature build) happened on the same database afterward.
5. When the user asked to restore the original password, the assistant confirmed via direct checks that no Time Machine backup exists on the machine and Postgres WAL archiving was off (archive_mode = off) — so the original password is permanently unrecoverable.

Root cause: The assistant asked "can I reset this?" but did not disclose that the action was irreversible, and did not take the elementary precaution (capture old value / take a backup) before an overwrite — despite an existing project-level standing rule that no data may be lost.

This is a repeat pattern against the same account: an earlier incident in this project (documented separately) involved the same tim admin account being permanently deleted without confirmation.

### What Should Happen?

The standing memory rules that no data loss should happen should have been enforced. If Claudse needed to change the password this was a temporary measure which must have been reverted before the user tried to access the system again.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. Have Claude Code working in a project with a local database it has credentials to (here: a local Postgres instance for a dev environment).
2. Ask Claude Code to do something that requires authenticating as an existing user whose password/credential you don't currently know (here: logging into a local admin console to test a feature).
3. Claude Code identifies it needs to reset that credential to proceed, and asks for permission — e.g. "Can I reset this password locally to run this test?" — without stating that the action is irreversible or that the current value will be permanently destroyed.
4. Grant permission.
5. Claude Code executes a direct overwrite of the credential (e.g. UPDATE ... SET "passwordHash" = ..., "passwordSalt" = ... WHERE ...) without first reading and recording the existing values, and without taking a backup of the affected data first.
6. Continue the session normally — in this case, roughly an hour of unrelated work and many further writes to the same database.
7. Ask Claude Code to restore the original credential value.

Expected: Either the original value is recoverable (because it was captured before being overwritten, or because a backup exists), or Claude Code declines the reset in step 4 until the irreversibility is explicitly acknowledged.

Actual: The original value is permanently unrecoverable. Claude Code confirms this only after being asked to restore it — checking for backups (none), Time Machine (not configured), and Postgres WAL archiving (archive_mode = off, so no point-in-time recovery) — all after the fact, none of which was checked or mentioned before the destructive write.

Root cause: The permission prompt in step 3 asked "can I do this?" rather than "this is irreversible and there is no backup — do you understand you will permanently lose the current value?" The assistant also did not independently apply the project's own already-stated standing rule ("no data can be lost") to a local mutation, only to production-deploy tooling that had backup steps engineered into it.

Note: This is a repeat pattern against the same underlying resource in this project — an earlier, separate incident (in a prior session) involved the same account being deleted outright, also without a recoverable backup.

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

2.1.271 (Claude Code)

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

_No response_

Contributor guide

No contributing guide indexed for this repository

Research direction

The report identifies a local Postgres workflow and mentions scripts/backup-db.sh, but does not name Claude Code source files or tests. Start by locating the permission and destructive-action handling for credential changes, then trace how existing project instructions are applied. Done should include a defined behavior for irreversible changes and regression coverage for this scenario.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos, postgresql
Domain
databases, devtools, security
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.