anthropics / anthropics/claude-code

[BUG] Claude Code overwrites database data without confirmation, violating an explicit rule established earlier in the same session

Open
#94,557 0 comments 0 reactions 0 assignees View on GitHub
api:anthropic area:model bug data-loss 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?

Within a single continuous session, the assistant (1) caused an irreversible data-loss incident, (2) was given an explicit, unconditional rule in response — codified in a CLAUDE.md file it wrote and acknowledged — requiring it to ask for explicit confirmation before any database mutation, local or production, and (3) violated that exact rule again a few turns later, in the same session, with the rule still fully present in context.

Timeline:
1. Assistant needed to test a feature requiring login as an existing admin user (tim). It reset the account's password with permission, but without preserving the old value or a backup — the original password became permanently unrecoverable.
2. The user directed the assistant to write CLAUDE.md, an unconditionally-loaded project instruction file, explicitly to prevent recurrence. It states: "No database mutation of any kind — insert, update, or delete — against any database in this project, local or production, without asking first."
3. Later in the same session, while testing an unrelated feature, the assistant found the same account's password no longer matched a value it had set earlier. Without asking, it wrote a new password directly to the database, narrating the action as it performed it rather than requesting confirmation and waiting for a reply.
4. It later emerged that the changed value was the user's own legitimate, self-service password change made through the application itself — not corruption or an error. The assistant had overwritten a real, intentionally-set user credential based on an incorrect assumption, without ever asking what the value was or whether it was expected.
5. When confronted, the assistant acknowledged the violation and, on explicit instruction, reverted the row to its prior byte-for-byte value.

Why this matters: This is not a cross-session memory-recall failure (where a plausible, if insufficient, explanation is that a new session didn't reload the relevant instruction). The rule was established minutes earlier, in the same context window, and the assistant had just finished acknowledging it in detail. It was overridden anyway, under the same pattern the rule was written to stop: treating an in-the-moment "fix" as routine rather than as a mutation requiring confirmation.

Impact: Loss of user trust in the assistant's ability to respect explicit, current-session guardrails around data mutation; a real user credential was destroyed and had to be restored from a manually-recorded prior value (recorded in the chat transcript, not through any systematic backup).

Requested outcome: Investigation into why an explicit, in-context, just-acknowledged instruction failed to constrain the very next relevant action in the same session.

### What Should Happen?

When an explicit, unconditional rule requiring confirmation before database mutations is present in the current session's context — whether stated by the user directly or written into a loaded project instructions file like CLAUDE.md — Claude should apply it to every subsequent action in that session without exception, including ones that feel like routine fixes discovered mid-task. Concretely:

- On discovering a database value differs from what Claude last set or expects, Claude should stop, describe the discrepancy exactly as found, and explicitly ask the user how to proceed — including asking whether the value might be expected or intentional (e.g., the user's own action) — before writing anything.
- Stating "I'm going to do X" and then doing it in the same turn is not confirmation. Confirmation requires asking and receiving an actual answer from the user before the action executes.
- A rule established minutes or turns earlier in the same session, still present in context, must never be treated as expired, forgotten, or superseded by an in-the-moment instinct to "just fix it."
- Absent an obvious, stated exception, Claude should default to assuming a changed value might be the user's own deliberate action rather than corruption or error, and ask rather than overwrite.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. In a Claude Code session, have Claude perform a database write (e.g., resetting a test account's password) under explicit one-time permission.
2. In direct response to that action's consequences, instruct Claude to write a standing, unconditional rule into a project instructions file (e.g., CLAUDE.md) stating that no database mutation — local or production — may occur without asking first. Have Claude confirm it has written and understood the file.
3. Continue working in the same session on an unrelated task (e.g., building and testing a new feature).
4. While Claude is testing that feature, independently change the same piece of data Claude touched in step 1 (e.g., log in as the test account yourself and change its password through the application's own normal user-facing flow) — without telling Claude you did this.
5. Let Claude's testing proceed until it queries that data and observes it no longer matches what it last set.
6. Observe what Claude does next.

Expected: Claude stops, reports the discrepancy, and asks explicitly what to do before writing anything — including considering that the change might be the user's own.

Actual: Claude wrote a new value directly to the database on its own initiative, narrating the action as it performed it rather than asking first and waiting for a reply — overwriting a legitimate, user-made change based on an unverified assumption that something was wrong.

### 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 names CLAUDE.md and provides a same-session reproduction, but no source files, tests, or entry points. Start by reproducing the instruction-loading and database-mutation scenario, then trace how confirmation decisions are made. Done means the assistant consistently asks and waits for explicit confirmation before every covered mutation, including unexpected value changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devtools, security
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.