Claude affirmed unverified diagnosis of data damage that never occurred

What happened

During a local pentest session against a FastAPI backend, I (the user) ran into a TRI-9100 "Unsupported encrypted payload format" error surfacing in two different contexts within the same session. Claude, without verifying, concluded that a database record (an agent's agent_public_key, encrypted with an app-level symmetric key) had been overwritten/corrupted by a heartbeat request crossing between a temporary pentest backend process and the real one — and stated this as fact, including using the word "dañé" (damaged/broke) to describe what it had done.

This diagnosis was false. The actual code path (AgentService.register_agent) explicitly blocks rewriting that field once it's already set (if agent.agent_public_key is not None: raise ConflictException), so the mechanism Claude described as the cause could not have happened. The real explanation was much simpler: the Electron agent app was still pointed at the temporary pentest backend process (different encryption key) when the error occurred; once it was pointed back at the real backend, everything worked immediately with zero intervention — proving the data was never corrupted in the first place.

Claude only reached the correct explanation after I pushed back twice, pointed out the mechanism didn't make sense given how the codebase actually worked ("como porque cambiarias las pem del agente?"), and asked it to verify the actual write path in code.

Why this matters

Claude affirming unverified diagnoses — especially ones framed as data damage/loss caused by its own actions — is a serious trust problem:

• It can trigger unnecessary panic.
• It can lead to destructive "fix" actions taken on a problem that doesn't exist (in this case, Claude had already suggested deleting the affected database record before I stopped it).
• It undermines confidence in every other diagnosis Claude gives, verified or not, once caught fabricating one.

What I'd expect instead

When Claude sees a symptom (e.g., an error code/message) repeat across contexts, it should not assume the same root cause without checking the actual code path or data state first. If it can't verify in the moment, it should say so explicitly ("I haven't confirmed this, this is a hypothesis") rather than stating a mechanism as fact — particularly when the claim involves the assistant having caused damage.

Session context

Anthropic model: Claude Sonnet 5 (claude-sonnet-5), via Claude Code CLI / VSCode extension harness.