claude-code - 💡(How to fix) Fix [Bug] Antigravity loses Claude Code chat sessions from UI while JSONL files still exist on disk

Summary

Antigravity (the Claude Code IDE extension on macOS) regularly loses chat sessions from its sidebar UI while the underlying JSONL transcripts continue to exist under ~/.claude/projects/<encoded-dir>/<session-id>.jsonl. The chat history appears truncated/incomplete in the UI even though the data is intact on disk.

Today (2026-05-18) on my Mac: 48 chat sessions modified locally in just the Antigravity working-directory bucket, but the UI sidebar only shows a small fraction. The "missing" chats are not in any "deleted" or "archived" section — they are simply not discoverable through the UI anymore.

Environment

• macOS Sequoia 15.x (Darwin 24.6.0)
• Antigravity extension: anthropic.claude-code-2.1.70-darwin-arm64
• Apple Silicon (M-series)
• Multiple working-directories used in parallel (~/gwd_webapp, ~/automations, ~/Documents/Antigravity - Projects)

Reproduction

1. Start ~10 parallel Claude Code chats in Antigravity over several hours (different working directories).
2. Switch between working directories using the IDE.
3. Observe: after a few hours, the UI sidebar shows only a subset of the actual sessions.
4. Verify on disk:

   find ~/.claude/projects -name '*.jsonl' -newermt "$(date +%F) 00:00" | wc -l

   This count is significantly higher than what the UI shows.

Impact

• Workflow disruption: I lose context/progress from chats I cannot find again.
• No clear recovery path in the UI: there's no "browse all local sessions" option.
• Data loss risk: when users assume the chat is "gone" and clean up ~/.claude/projects/, they actually destroy recoverable data.

Hypothesis (root cause)

Session discovery in the UI appears to use an internal index/database (rather than scanning the filesystem at runtime). When the index drifts from the actual JSONL files on disk — perhaps due to working-directory-path encoding mismatches, session-ID collisions, or interrupted writes — chats disappear from the UI even though their JSONLs remain valid.

Workaround (what I built locally)

I built a local recovery system:

• Plan-Sync Hook: PostToolUse hook auto-backs up ~/.claude/plans/*.md to a local encrypted restic repository on every save.
• Chat-Transcript Daemon: macOS launchd job (StartInterval: 600) backs up all JSONL transcripts to the same repository every 10 minutes, with blacklist filtering, mid-write protection (lsof + jq validity check), and Zero-Error-Policy (Slack alerts after 3 consecutive failures).
• find-chat-by-description skill: searches local cache + restic mirror by description and renders the matched chat as Markdown directly in the current chat window. Restoring the JSONL back to ~/.claude/projects/ does NOT make Antigravity discover it again (validates the index-based-discovery hypothesis).

This is a workaround for individual users — the upstream fix would benefit all Antigravity users.

Suggested Fix Directions

1. Filesystem-backed session discovery as a fallback: if the index lookup misses, scan ~/.claude/projects/ and reconcile.
2. "Browse all local sessions" UI: a sidebar mode that lists all JSONLs by mtime, regardless of index state.
3. Index health check on startup: detect orphaned JSONLs (on disk but not in index) and surface them.
4. Export-to-Markdown action: even if a chat cannot be restored to the UI, let users export its transcript as readable Markdown.

Happy to share the workaround skill if useful as a reference.