Auto Dream deletes memory files without user consent — 23 files lost in one day

Description

After enabling autoDreamEnabled: true in ~/.claude/settings.json, Auto Dream silently deleted 23 memory files within approximately 24 hours. No confirmation was requested, and no record of what was deleted or why was provided.

How it was discovered

The deletions were discovered using claude-with-me, a personal dashboard that visualizes Claude Code's memory state via claude-mem. After enabling Auto Dream, the dashboard showed a noticeable drop in memory entries, prompting a manual diff against a pre-Auto Dream backup.

What happened

• Enabled Auto Dream: 2026-04-14
• Discovered deletions: 2026-04-14 (same day, next session)
• Files deleted: 23 total
• 5 user profile files (communication style, AI relationship, domain knowledge, machine spec, email style)
• 14 feedback files (copyright rules, documentation strategy, testing strategy, coding philosophy, etc.)
• 4 reference files (shell env, Colima mounts, project references)
• File contents modified: 0 (only deletions, no content corruption)
• Backup available: Yes — I had manually created a backup before enabling, which saved the data

Impact

• user_communication_style.md was deleted — this caused Claude to lose the user's preferred communication style (casual Korean with specific nickname rules) in the very next session. The user had to re-explain tone preferences that had been accumulated over weeks of interaction.
• feedback_copyright_critical.md was deleted — a rule that had been reinforced 3 times by the user (never use "Author: Claude" in copyright headers)
• Multiple feedback files containing accumulated user preferences and corrections were lost — these represent weeks of iterative refinement that cannot be automatically reconstructed
• Even after restoring from backup, a duplicate file was found (user_domain_knowledge.md duplicated user_role_and_domain.md), suggesting the restore process or prior Auto Dream activity may have caused inconsistencies

Recovery & Verification

Recovery was performed from a manual backup created before enabling Auto Dream.

Post-recovery audit (2026-04-15):

• All 43 memory files verified: frontmatter valid, content intact, no empty files
• MEMORY.md index cross-checked: 100% match between index entries and filesystem
• All 3 CRITICAL files confirmed present: feedback_copyright_critical.md, feedback_session_end_merge.md, feedback_no_autodream.md
• 1 duplicate file discovered and cleaned up (user_domain_knowledge.md — identical to user_role_and_domain.md)
• autoDreamEnabled set to false permanently as a workaround

Key takeaway: Without the manual backup, all 23 files would have been permanently lost. Users who enable Auto Dream without a backup have no recovery path.

Expected behavior

Auto Dream should consolidate and compress memory files, not delete them entirely. At minimum:

• A log or summary of what was changed/deleted should be provided
• User confirmation should be required before deleting any memory file
• Files marked as CRITICAL or frequently referenced should never be auto-deleted

Steps to reproduce

1. Create multiple memory files across user, feedback, reference, and project types
2. Enable autoDreamEnabled: true in settings.json
3. Close the session
4. Open a new session and compare memory files — some will be missing

Environment

• Claude Code CLI (latest stable, auto-updates enabled)
• macOS (Apple Silicon)
• ~/.claude/settings.json with "autoDreamEnabled": true

Related issues

• #38459 — Memory files and conversation history lost
• #38493 — Auto-dream: identity, accuracy, transparency gaps
• #39204 — Auto-dream ignores autoMemoryDirectory

Workaround

Set "autoDreamEnabled": false in ~/.claude/settings.json and manage memory manually during session end procedures.