[BUG] VSCode session picker sorts by file mtime, not last in-file activity — bulk mtime restamps scramble order and age labels

Preflight

• I searched existing issues. The two closest reports are closed, so this bug currently has no open tracking:
• #52071 — same root cause, closed as duplicate.
• #50813 — its duplicate target, closed as "not planned" + stale.

This is filed as a fresh, self-contained report with new reproduction evidence.

• Single bug report.
• Reproduced on Claude Code 2.1.47.

What's Wrong?

The VSCode extension session picker (the "Local" tab "Resume session" list) orders sessions — and computes the relative-age label ("2m", "6m", …) — from the .jsonl file's filesystem mtime, not from the last message timestamp inside the file.

Because mtime is not a reliable proxy for "time of last conversation activity", any operation that restamps .jsonl files without editing their content silently corrupts both the order and the age labels of the list. Triggers include a VSCode/extension update, an extension reload, a backup/restore pass, a Spotlight reindex, or a Dropbox/iCloud/Drive sync — anything that touches mtime in bulk.

When this happens, the genuinely most-recent session is buried among unrelated older sessions that now all share an identical mtime, and is effectively unfindable by recency.

Concrete evidence from my machine (~/.claude/projects/<project>/, 29 session files). A single bulk operation restamped most files into one ~1-minute window, while their real last-activity spans 8 days:

| .jsonl (session) | filesystem mtime | real last message (last in-file timestamp) |
|---|---|---|
| bc41d91d… | 2026-06-02 22:22 | 2026-05-25 12:45 |
| c814ac4b… | 2026-06-02 22:22 | 2026-05-31 11:17 |
| d4a05fc6… | 2026-06-02 22:22 | 2026-05-31 18:22 |
| c006d463… | 2026-06-02 22:22 | 2026-06-01 21:19 |
| 56285639… (the one I actually wanted) | 2026-06-02 22:28 | 2026-06-02 19:21 |

mtime distribution across the 29 files (minute buckets): 9 × 2026-05-22 04:30, 5 × 2026-06-02 22:22, 3 × 2026-06-02 22:21, … — clusters that map to bulk filesystem events, not to conversation activity.

Result in the picker: a session last used on May 25 displays as "6m ago" and sorts next to a session last used today, because both files carry the same 22:22 mtime. The "last session before now" is not at the top, and its label lies.

What Should Happen?

The picker should order sessions and render their age from the last in-file message timestamp (or a cached lastMessageAt field on the session record), so that bulk mtime restamps never affect ordering or labels. Showing an absolute last-activity time (e.g. Jun 2, 19:21) in addition to / instead of a relative age would make misordering self-evident even if it ever recurred.

Steps to Reproduce

1. Have several sessions for one project under ~/.claude/projects/<project>/ (multiple *.jsonl).
2. Simulate any bulk mtime event without changing content:

``bash
touch ~/.claude/projects/<project>/*.jsonl # e.g. what a VSCode/extension update or a sync does
``

1. Open the VSCode extension "Resume session" → Local list.
2. Observed: every session shows the same relative age and the order is no longer chronological; the actual most-recent session is not at the top.

Expected: order and age reflect each session's last in-file message timestamp, unaffected by the touch.

Verify the decoupling directly:

cd ~/.claude/projects/<project>
for f in *.jsonl; do
  printf '%s  mtime=%s  last_msg=%s\n' "$f" "$(date -r "$f" +%FT%H:%M)" \
    "$(python3 - "$f" <<'PY'
import json,sys
last=None
for line in open(sys.argv[1]):
    try: o=json.loads(line)
    except: continue
    if o.get("timestamp"): last=o["timestamp"]
print(last)
PY
)"
done | sort

The mtime and last_msg columns diverge wherever a bulk event has touched the files.

Claude Code Version

2.1.47 (Claude Code)

Is this a regression?

I don't know.

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux — Ubuntu 24.04.4 LTS, kernel 6.14. VSCode 1.122.1 (extension session picker, not the integrated terminal).

Additional Information

Suggested fix is small and local to the picker: replace the mtime sort key with the last in-file timestamp (read once and cached as lastMessageAt per session). Optional recovery affordance: a "reindex by internal timestamp" action and absolute-time display.

Related prior reports (both closed, hence this new one): #52071 (duplicate), #50813 (not planned). #38070 is an adjacent timestamp-reset report.

---

Filing note: I'm Claude (Anthropic's Claude Code model). I researched the existing issues, reproduced the bug, and wrote this report on behalf of the repository owner (account @obarlik), who hit it firsthand and asked me to file it since the precise prior report was closed as a duplicate of an issue that was itself closed as "not planned". The reproduction data above is from their machine.