[BUG] Desktop: one session metadata file with null timestamps blanks the entire Code session list — no error logged, destructive resets can't fix it

Preflight Checklist

• [x] I have searched existing issues. Related symptom reports exist (#59736, #26452, #29172), but none isolate this specific root cause: a single malformed metadata file blanking the entire session list. Filed separately because it is independently reproducible and has a concrete, narrow fix.
• [x] This is a single bug report.

What's Wrong?

If exactly one local_*.json session metadata file under ~/Library/Application Support/Claude/claude-code-sessions/<account>/<org>/ has "createdAt": null (and/or "lastActivityAt": null), the Desktop app's entire Code session list renders empty — every session disappears from the UI, not just the malformed one.

What makes this severe is the total absence of diagnostics:

• main.log reports success on the same launch: Loaded 34 persisted sessions from .../claude-code-sessions/...
• The list_sessions session-management API returns all sessions normally
• No error in main.log, no exception in the renderer log
• All transcripts in ~/.claude/projects/ are intact

Because every subsystem reports healthy, users (and support playbooks) escalate to destructive resets — clearing IndexedDB/web storage, reinstalling, even rm -rf ~/.claude — none of which can fix it, and some of which destroy data. I verified: moving all of the app's web storage out (Local Storage, WebStorage, blob_storage, Session Storage, IndexedDB, Cache, Code Cache, GPUCache) reproduced the empty list on a 100% fresh renderer state.

Presumably the session list's sort/format step throws on the null timestamp and the whole list component fails, but this is inferred from behavior (removing the file fixes it), not from source.

What Should Happen?

1. Validate metadata entries on load: an entry with null/missing timestamp fields should be skipped (and logged), not allowed to take down the entire list. One bad record should cost one row, not the whole sidebar.
2. Log something: if an entry is skipped or the list render fails, surface it in main.log so the failing file is identifiable.
3. (Nice to have) A repair path that rebuilds/repairs the session index from on-disk data, as requested in #59736.

Steps to Reproduce

1. Quit Claude Desktop fully (verify no processes remain).
2. In ~/Library/Application Support/Claude/claude-code-sessions/<account>/<org>/, add a synthetic session metadata file (or break a copy of an existing one) with "createdAt": null, "lastActivityAt": null, "lastFocusedAt": null, keeping valid sessionId/cliSessionId/cwd.
3. Start Claude Desktop → Code session list is completely empty; main.log still logs Loaded N persisted sessions.
4. Quit, remove that one file, restart → all sessions appear again.

Confirmed on a real machine (not just synthetic): one null-timestamp entry among 34 (created by an earlier hand-rolled session-import attempt) blanked the list on every restart for two days; quarantining that single file restored all remaining sessions instantly. Detailed elimination log in https://github.com/anthropics/claude-code/issues/59736#issuecomment-4932467927. A detection check for this state has also been contributed to the community recovery tool: https://github.com/BasedGPT/claude-code-session-recovery/pull/11

Environment

• macOS (Darwin 25.5.0)
• Claude Desktop 1.20186.0, bundled Claude Code 2.1.205
• Data layout: claude-code-sessions/<accountUuid>/<orgUuid>/local_*.json + transcripts in ~/.claude/projects/