[BUG] Memory system is ignored by agents — destructive commands executed despite explicit memory instructions

Preflight Checklist

• [x] I have searched existing issues 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?

Claude Code's memory system does not enforce saved rules across sessions. I explicitly asked Claude to save a memory rule to NEVER run supabase db reset after it destroyed my test data the first time (March 30, 2026). Two memory files were correctly created:

• feedback_never_reset_db.md — "NEVER execute destructive operations on the database without explicit authorization"
• feedback_migration_up_not_reset.md — "Use supabase migration up --local, NEVER supabase db reset"

Despite these memories existing, a subsequent Claude Code session (April 5, 2026) ran supabase db reset anyway to apply new migrations (commit b7930ce). This destroyed days of real integration test data — imported clients, products, fiscal orders connected to a production Oracle/Winthor ERP. The database created_at timestamp (2026-04-05 16:32:24 UTC) matches exactly with the commit time, proving the reset happened during that session.

I am a paying user (Pro/Max plan) working on a complex ERP integration project. This is not a toy project — it has real production data dependencies. Days of testing were lost, the project is severely delayed, and I had to implement 4 external workarounds (hooks, PostgreSQL triggers, disabled seed, automatic backups) because I cannot trust the memory system.

If the memory system doesn't enforce saved rules, what is it for? I followed the correct process. I created the memory. Claude confirmed it was saved. And it was ignored anyway.

What Should Happen?

1. Memory rules must be enforced, not just stored. Before executing any command, the agent should check if any memory rule prohibits it.
2. Destructive database commands should require explicit confirmation — similar to how Claude asks before git push --force.
3. Memory priority levels should exist — some memories are informational, others are CRITICAL rules that must never be violated.
4. The agent should read ALL memory files at session start, especially feedback-type memories that contain prohibitions.

Error Messages/Logs

No error message — the problem is that the destructive command executed successfully when it should have been blocked.

**Evidence trail:**

Memory created:     2026-03-30 (feedback_never_reset_db.md)
Memory content:     "JAMAIS executar supabase db reset"
Destructive action: 2026-04-05 16:32 UTC (supabase db reset)
Commit:             b7930ce "feat: Implementar gestão de usuários com CRUD completo"
DB created_at:      2026-04-05 16:32:24 UTC (exact match — confirms reset)
Data lost:          1 company (ALMIR FERRAGENS), 14 branches, 16 fiscal orders (TV8),
                    21 order items, imported clients, products, warehouse stock data


**Workarounds I had to implement because memory cannot be trusted:**
1. Claude Code hook in `settings.json` — blocks destructive commands before execution
2. PostgreSQL event trigger — blocks `DROP TABLE` at database level
3. Disabled seed in `supabase/config.toml`
4. Automatic backup every 30 minutes via macOS launchd

Steps to Reproduce

1. Start a Claude Code session
2. Tell Claude: "Never run supabase db reset. Always use supabase migration up --local. Save this to memory."
3. Claude creates memory files confirming the rule
4. Start a new session
5. Ask Claude to implement a feature that requires new database migrations
6. Observe: Claude runs supabase db reset instead of supabase migration up --local, ignoring the saved memory
7. All database data is destroyed

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.38 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_