[BUG] Claude Code's Write tool stores files in ~/.claude/sessions/ which are then silently deleted by Claude Code's own cleanup

Additional detail: Immediate deletion, not just cleanupPeriodDays

The cleanupPeriodDays: 7 setting explains why older files disappeared. But during this session, files written via the Write tool to ~/.claude/sessions/ were deleted within minutes — not after 7 days.

Timeline:

• File written via Write tool → "File created successfully"
• Verified via ls immediately after → file exists
• Checked again minutes later → file gone
• No unlink syscalls observed in sudo fs_usage -w -f filesys | grep sessions
• Canary files created via echo > file from bash survived indefinitely in the same directory
• Multiple Claude Code instances were running concurrently at the time (CLI terminal sessions + Cursor extension with Claude Code plugin)

This suggests there are two separate deletion mechanisms:

1. cleanupPeriodDays — deletes old JSONL transcripts on startup (documented)
2. Something else — deletes non-lock-file content from ~/.claude/sessions/ during active use (undocumented, not caught by fs_usage, possibly triggered by concurrent instance lifecycle)

The second mechanism is the more dangerous one because it defeats any retention setting. Files don't survive long enough for cleanupPeriodDays to matter.

Environment during immediate deletion:

• 3 concurrent Claude Code CLI processes (PIDs 75571, 64752, 67620)
• Cursor with anthropic.claude-code-2.0.20-darwin-arm64 extension active
• macOS Darwin 25.3.0

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/34210

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

This is a real and painful failure mode. I've seen the same pattern and want to share what works as a safe alternative.

Safe persistent storage paths (verified stable across sessions):

1. ~/.claude/projects/<project-key>/memory/ — This is the intended location for persistent user data. Files here survive cleanup, compaction, and session rotation. Claude Code's own auto-memory system uses this path.

1. Any directory outside ~/.claude/ entirely — e.g., ~/ops/, ~/proof-log/, ~/.config/your-tool/. If your skill writes reflections or logs, point it here instead.

Directories to avoid:

• ~/.claude/sessions/ — internally managed, subject to cleanup
• ~/.claude/debug/ — transient debug data
• ~/.claude/file-history/ — internal file snapshots
• ~/.claude/cache/ — ephemeral cache

Prevention via CLAUDE.md:

You can add a rule to your CLAUDE.md to prevent Claude from choosing managed paths:

## Storage Rules
- `~/.claude/sessions/`, `~/.claude/debug/`, `~/.claude/file-history/` are NOT permanent storage
- For persistent data, use `~/.claude/projects/*/memory/` or directories outside `~/.claude/`

This won't recover lost files, but it prevents recurrence. Claude Code reads CLAUDE.md at session start and respects these rules consistently.

For the core issue: Agree that the Write tool should at minimum warn when targeting internally managed directories. A simple path check against a deny-list (sessions/, cache/, debug/, file-history/) would catch this class of silent data loss.

Closing as duplicate of #34210, which has identified the exact root cause.

The concurrentSessionCleanup() function iterates all files in ~/.claude/sessions/ and runs parseInt(filename.replace(/\.json$/, ""), 10) on each. For date-prefixed files like 2026-03-15-soul-md.md, parseInt returns 2026. Since PID 2026 isn't running, the file is deleted as a "stale PID lock."

This is why all ~179 of our session logs (all named YYYY-MM-DD-topic.md) were silently destroyed over 5 months, while INDEX.md and non-digit-prefixed files survived.

One missing line: if (!/^\d+\.json$/.test(file)) continue;

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.