Local ~/.claude directory (settings, skills, per-project memory) silently reset on disk, while ~/.claude.json history stays intact

Status Open
Reported on v2.1.267
Maintainer reply None cached
Activity 3 comments · opened Sep 10, 2026

Description

The ~/.claude directory (which holds settings.json, any custom skills/, and per-project memory/ files under projects/<hash>/) appears to have been silently recreated/reset locally, while the separate ~/.claude.json file (account/OAuth/project registry with usage history) remained fully intact.

Evidence

  • ~/.claude.json shows numStartups: 209, firstStartTime: 2026-03-27, and a full registry of ~20 long-tracked project checkouts with per-project cost/session history — clearly untouched, long-lived data.
  • ~/.claude/ (the directory itself) has a filesystem birth time of 13:29:16 local, today — i.e. it was empty/fresh as of that moment. settings.json inside it was reduced to just {"model": "opus[1m]"}, any previously-configured custom skills under .claude/skills/ are gone (directory doesn't exist), and the per-project memory/ folder for at least one long-worked-on project was completely empty.
  • ~/.claude/.last-cleanup contains a timestamp of 2026-09-10T18:33:13.541Z (14:33:13 local) — a marker apparently written by Claude Code's own internal housekeeping shortly after the reset.
  • I checked Windows Event Viewer (System, Application, Security, Symantec Endpoint Protection, AAD/device-management logs) around 13:29 local. No OS-level process, installer, security product, or management policy touched anything at that time. The device is also not MDM/Entra managed ("Machine is governed by none policy"), ruling out an external enterprise wipe policy.
  • The only OS event near that time is a Modern Standby wake-up at 13:27:28 local, ~2 minutes before the .claude folder's birth time.

Since no external actor (AV, MDM, installer) shows up in the OS logs, and Claude Code itself wrote a .last-cleanup marker minutes after the reset, this looks like it originated from Claude Code's own local state/cleanup logic rather than anything the user did (no destructive command was run, and the separate ~/.claude.json file was left alone).

Impact

  • Custom skills previously configured under ~/.claude/skills/ were lost.
  • settings.json was reset to defaults.
  • Per-project memory files (~/.claude/projects/<hash>/memory/*.md) for at least one actively-used project were wiped/empty, despite months of prior usage on the account (numStartups: 209).

Environment

  • OS: Windows 11 Pro 10.0.26200
  • Claude Code version: 2.1.267 (lastVersionBase in ~/.claude.json)
  • Install method: native (per ~/.local/share/claude, ~/.local/state/claude layout)

Request

Could someone from the team clarify what internal process writes ~/.claude/.last-cleanup and under what conditions it (or another startup routine) would reset/recreate the ~/.claude directory contents (settings, skills, per-project memory) while leaving ~/.claude.json untouched? This looks like a bug in local state handling that can silently destroy user configuration and memory data without any corresponding log trace or user action.

🤖 Generated with Claude Code

View original on GitHub ↗

3 Comments

artembilan · 3 days ago

Hi!
I asked my Claude Code about session we have started working on around that time:

Planning start: 2026-09-10T18:23:15Z — 14:23:15 EDT. The /model command is the very first entry, at 18:23:15.188Z; your actual ask about <SUBJECT> came at 18:24:42Z, and /login at 18:31:55Z.

So, feels like "cleanup" in the ~/.claude/ has happened after authentication into account.

Thank you!

artembilan · 2 days ago

OK. Just opened a new Claude session today.
It asks for /login again and what is bad it has cleaner ~/.claude/ directory. No memory, no skills. Projects are cleared, too.

I don't know how to escalate this, but looks like Claude Code v2.1.268 is at fault.
Perhaps just on Windows, but the problem is there.

Thanks

artembilan · 2 days ago

OK. I was able to restore my memory and skills using Claude advice for vssadmin list shadows /for=C: and then mklink /d C:\ShadowCopy ....

Still not clear what exactly removed content of that dir.
Will keep a pulse on it!