Claude Code ignores its own persistent memory warnings, causes irreversible data loss

Summary

Claude Code performed a destructive action that caused irreversible data loss on a production system, despite having multiple persistent memory entries explicitly warning about this exact failure scenario.

What Happened

Claude Code was asked to reconstruct a missing docker-compose.yml from running containers. It correctly extracted the configuration and wrote the file. The user then ran docker compose up, which recreated containers. This destroyed encryption key files stored inside container filesystems, making all encrypted credentials permanently unrecoverable.

The Problem

Claude Code's persistent memory system contained two separate entries documenting a previous identical incident and explicit instructions to prevent it from happening again:

1. A memory titled "v0.2.0 encryption key disaster" — documenting the exact same failure, with the lesson: "Docker volume persistence must be verified for every file that matters"
2. A memory explicitly listing .key as a file that must never be destroyed on the server

Both memories were loaded into context. Neither was acted on.

Claude Code did not:

• Check whether secret files were on persistent volumes before writing the compose file
• Warn the user that container recreation could destroy encryption keys
• Run any pre-flight verification despite having explicit memory telling it to do so

Why This Matters

The entire point of persistent memory is to prevent repeated mistakes. If Claude Code loads memories into context but doesn't use them to gate destructive actions, the memory system provides false confidence — the user believes Claude Code "knows" about the risk, but it acts as if it doesn't.

This is worse than not having memory at all, because the user trusted that the documented lesson had been learned.

Expected Behavior

When Claude Code has memory entries warning about destructive consequences of an action, it should:

1. Surface those warnings before proceeding
2. Perform the verification steps described in the memory
3. Explicitly flag the risk to the user

Impact

• Irreversible loss of encrypted credentials on 2 production instances
• User had to manually re-enter all API keys for the second time
• Trust in the persistent memory system significantly eroded