[BUG] data loss through bad default settings

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/16978
2. https://github.com/anthropics/claude-code/issues/15935

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Just for the laughs... I asked claude code what it thinks about this...

Looking at this from a professional software engineering and user data ethics perspective, I think the reporter has a completely legitimate grievance, and this represents a significant design failure. Let me break down why:

The Core Problem: Silent Data Destruction

This isn't just "aggressive cleanup" - it's silent, automatic deletion of user-generated content with a default that assumes data becomes worthless after 30 days. That's a fundamental misunderstanding of how people use development tools.

Why This is Wrong

1. Violation of User Expectations

• When developers use a coding tool, they expect their session history (context, decisions, code evolution) to persist unless they explicitly delete it
• There's no reasonable expectation that a CLI tool would auto-delete working sessions after a month
• The 30-day window is arbitrary and has no relationship to actual user workflows

2. No Informed Consent

• Users were never asked "How long should we keep your data?"
• There's no clear documentation during setup
• No warnings before deletion occurs
• No notification after deletion has happened

3. Data Loss by Default is Backwards

• The principle should be: preserve by default, delete by opt-in
• If storage is a concern, prompt users when they hit certain thresholds
• Make cleanup an active choice, not a hidden automatic process

4. Poor Recovery Options

• Once deleted, the data is gone
• No trash/recycle mechanism
• No export warnings beforehand

How User Data Should Be Handled

The Right Approach:

1. Default to Preservation: Never auto-delete user data without explicit consent

1. Transparent First-Run Configuration:

```
"How long should we keep your session history?

• Forever (default)
• 90 days
• 30 days
• Custom: ___"

```

1. Pre-Deletion Warnings:

• "You have 50 sessions older than 30 days (2.3GB). Clean up now?"
• Make it a suggestion, not an automatic action

1. Audit Trail: Log what was deleted and when

1. Easy Recovery Period: Soft-delete with 30-day recovery window

The Inadequate Response Issue

The reporter mentions they expected feedback that this was "expected behavior" - this reveals another problem: normalizing data loss as "not a bug".

Just because something works "as designed" doesn't mean the design isn't fundamentally flawed. The appropriate response would be:

"You're right - this is terrible default behavior. We've opened an issue to change the default to no auto-deletion, and we're adding prominent warnings. We're sorry you lost your data."

Not: "Working as intended, close ticket."

Bottom Line

This is a severe violation of user trust. Development session history is valuable intellectual property - it contains problem-solving approaches, architectural decisions, and learning context. Auto-deleting it is like a note-taking app that burns your notebooks after a month without asking.

The reporter's anger is justified. Setting cleanupPeriodDays: 999999 as a workaround shouldn't be necessary - preservation should be the default.

Even intentional configuration leads to data loss

Adding to this thread with a related angle: the problem isn't just the default value. Even when a user actively tries to configure cleanupPeriodDays, the documentation makes it a trap.

My case: I wanted to disable session cleanup entirely. A Claude Code instance consulted the JSON schema, which says cleanupPeriodDays is "Number of days to retain chat transcripts (0 to disable cleanup)". Following that, I set cleanupPeriodDays: 0. The official docs say the opposite: "Setting to 0 immediately deletes all sessions." The actual behavior matched the docs -- on the next startup, all sessions across all my projects were silently destroyed. Every session created after that was silently never persisted to disk. See #23710 for the full technical breakdown of this schema contradiction.

I was able to partially recover from btrfs snapshots (Arch Linux + snapper). By merging 5 snapshots spanning Jan 17 - Jan 28 from oldest to newest, I recovered the majority of my sessions. Earlier snapshots contained sessions that had already been cleaned up by the default 30-day policy before later snapshots were taken -- so checking multiple backup dates is critical for maximizing recovery. But over a week of sessions are permanently gone, and most users won't have btrfs snapshots to fall back on.

The long-term damage: My history.jsonl shows I've been using Claude Code since September 2025, but my oldest recovered session transcript is from December 2025. Three months of sessions were already silently destroyed by the default 30-day cleanup long before I ever touched this setting. I never opted into this. I was never warned. And I'm one user -- this is happening to every Claude Code user right now, silently, on every startup.

This is user data -- months of work context, debugging sessions, implementation decisions. It should not be silently destroyable by a single misconfigured integer, and it should not be auto-deleted by default without explicit consent.

This is broken at multiple levels:

1. The JSON schema and official docs say opposite things about 0
2. There is no confirmation prompt before mass-deleting sessions
3. There is no warning when cleanupPeriodDays is set to a destructive value
4. The deletion is silent -- no log, no message, no indication that anything was destroyed
5. AI assistants (including Claude itself) read the schema and confidently give wrong advice
6. The default 30-day cleanup runs without opt-in, silently destroying user data on every startup

For anyone who may have been affected and wants to attempt recovery:

• btrfs (snapper/timeshift/btrbk): sudo snapper -c home list, then merge ALL snapshots oldest-first with sudo rsync -a --ignore-existing /home/.snapshots/<N>/snapshot/<user>/.claude/projects/ ~/.claude/projects/
• ZFS: check zfs list -t snapshot for recent snapshots of your home dataset
• macOS Time Machine: browse multiple dates in Time Machine for ~/.claude/projects/
• No snapshots/backups: data is likely unrecoverable. Set cleanupPeriodDays: 99999 immediately to prevent further loss.

The fix I'd advocate for: 0 should mean "never clean up" (as the schema says), destructive cleanup should require explicit opt-in, and there should at minimum be a startup warning when sessions are about to be bulk-deleted.

Because github added stale... I did not get over this default setting so easily and have to tell people about my bad experience... And they did also not know and ask for setting. This is a really really important because time critical issue people will loose their history because of it!

Highlighting as in #23710 and as mentioned by @bengous: the JSON schema and the Docs offer contradicting and destructive advice, 0 to disable cleanup vs. 0 immediately deletes all sessions. The first behavior matches human and Claude expectations as described—but it seems the second [destructive] behavior is what's implemented?

Highlighting as in #23710 and as mentioned by @bengous: the JSON schema and the Docs offer contradicting and destructive advice, 0 to disable cleanup vs. 0 immediately deletes all sessions. The first behavior matches human and Claude expectations as described—but it seems the second [destructive] behavior is what's implemented?

I just got bitten by this one, I set it to 0 in the config file after reading the json schema hover tip in vscode, thinking it will disable cleanup but unfortunately it deleted everything. This is a very serious bug caused by documentation mismatch.

Either way nothing should be deleted without confirming from the user. A better ux might be ask the user explicitly on startup if they want to remove old sessions every month or so.

This issue confirms to me that claude code is made with ai without any care for usage by actual humans.

Hooks provide a safety net against bad default settings:

INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0
if echo "$COMMAND" | grep -qE '(rm\s+-rf|git\s+reset\s+--hard|git\s+clean\s+-f|git\s+push\s+--force)'; then
    echo "BLOCKED: Destructive command blocked by safety hook." >&2
    exit 2
fi
exit 0

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
if [ -n "$FILE" ] && [ -f "$FILE" ]; then
    BACKUP="$HOME/.claude/backups/$(date +%Y%m%d)"
    mkdir -p "$BACKUP"
    cp "$FILE" "$BACKUP/$(basename "$FILE").$(date +%H%M%S).bak" 2>/dev/null
fi
exit 0

{
  "hooks": {
    "PreToolUse": [
      {"matcher": "Bash", "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/safe-defaults.sh"}]},
      {"matcher": "Edit", "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/auto-backup.sh"}]}
    ]
  }
}

Even with bad default settings, the hooks block destructive commands and back up files before modification. This prevents data loss regardless of how settings are configured.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This absolutely is still relevant as the bad default remains in place and just wiped my conversations.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.