claude-code - 💡(How to fix) Fix Session picker sorts by file mtime; OS/IDE events that touch mtime scramble chronological order [1 comments, 2 participants]

Summary

The VSCode extension session picker ("Local" tab) appears to sort sessions by the .jsonl file's filesystem mtime rather than by the last message timestamp inside the file. Any event that restamps mtimes without editing content — a VSCode update, an extension reload, a Time Machine pass, a Spotlight reindex, a Dropbox/iCloud sync, a find … -exec touch — silently reorders the picker and can bury the actual most-recent session under older ones.

Repro (what I hit today)

1. Had a long active session in this project (6+ hours of work, last message at 2026-04-22T17:38:31Z).
2. Updated VSCode (~30s). The update run touched ~200 .jsonl files in ~/.claude/projects/<project>/, rewriting their mtimes to within a ~30-second window at roughly 2026-04-22 10:40 local.
3. Reopened Claude Code → new chat auto-started.
4. Opened the session picker to resume. Every session showed the same relative label ("5m"), and the ordering no longer reflected recency. A session whose last internal message was 2 days ago (2026-04-20T20:39Z) ranked near the top; the session I'd been working in (true last message 6 min ago) was buried several entries down.

Evidence the data itself is fine

• Inside each .jsonl, message timestamp fields are correct.
• Sorting by the last internal timestamp across all files instantly gives the true most-recent session:

  for f in ~/.claude/projects/<project>/*.jsonl; do
    echo \"$(tail -c 30000 \"$f\" | grep -oE '\"timestamp\":\"[^\"]+\"' | tail -1) $f\"
  done | sort -r | head -5

• ls -lat showed ~200 files all sharing the same Apr 22 10:40 mtime — physically impossible for genuine activity; the OS/extension touched them all inside one short window.

Suggested fix

Sort the picker by lastMessageAt read from the JSONL (last timestamp field, or a cached field on the session), not by file mtime. mtime is not a reliable proxy for "time of last conversation activity" because many OS-level and IDE-level events modify mtime without editing content.

Why it matters

When a user has many sessions per project (I have 218 in this one), the picker ordering is the only way to find a specific conversation to resume. If ordering silently breaks after routine events like an IDE update, the user reasonably concludes their chat history was lost (I did). Recovery is possible by reading internal timestamps, but that requires a shell and knowing where the files live.

Environment

• macOS (Darwin 25.3.0)
• VSCode native extension
• Shell: zsh
• Session count in affected project: 218 files
• Update that triggered it: routine VSCode update (~30s), no extension-specific action taken

Nice-to-haves (optional)

• Show absolute last-activity time, not just a relative 5m label, so users can spot a stale sort.
• A "Reindex by internal timestamp" action in the picker for recovery after this class of event.