[BUG] /resume shows old sessions as recently modified because file timestamps get bumped

Status Open
Reported on v2.1.212
Maintainer reply None cached
Activity 2 comments · opened Jul 20, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When I open /resume to pick an earlier chat, sessions I haven't touched in days or weeks show up as "modified" just minutes ago, and they jump to the top of the list. This makes it hard to find the session I actually used most recently.

Looking at the files on disk (~/.claude/projects/<project>/*.jsonl), the last real message in these sessions is genuinely days old, but the file's modification time has been changed to a recent time — without any new message being added. It looks like a background process (session sync between the CLI and the desktop/web app) rewrites the older session files, which updates their timestamps. /resume seems to sort and label by that file timestamp, so the list ends up misleading.

The conversations themselves are fine — nothing is lost or corrupted. It's only the "modified" time and the ordering that are wrong.

What Should Happen?

/resume should order and label sessions by the time of the last actual message in each conversation, not by the file's modification time. A background rewrite that adds no new messages shouldn't move a session to the top or change its displayed "modified" time.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

  1. Use Claude Code across a few days so several sessions build up.
  2. Have the same account connected to the desktop/web app (so sessions sync).
  3. Wait for a sync to happen (older session files get rewritten in the background).
  4. Run /resume.

Expected: sessions ordered by when I last messaged in them.
Actual: sessions I last used days ago appear as "modified" minutes ago and sit at the top.

To confirm it's the file timestamp and not the content, compare each file's modification time against the last message inside it:

cd ~/.claude/projects/<project>/
for f in *.jsonl; do
m=$(stat -c '%y' "$f")
last=$(grep -o '"timestamp":"[^"]"' "$f" | tail -1 | sed 's/.:"//;s/"//')
echo "mtime=$m last_msg=$last $f"
done

On my machine, several files show a modification time about a week newer than their last message, for example:

mtime 2026-07-20 20:34 last message 2026-07-13T12:35 (7 days apart)
mtime 2026-07-20 20:25 last message 2026-07-16T09:30 (4 days apart)
mtime 2026-07-20 20:42 last message 2026-07-17T19:15 (3 days apart)

One extra clue: the bumped files all have modification times rounded to the millisecond (ending in .000000), while files written live by the CLI have full nanosecond timestamps. That suggests a separate program set the time after downloading the file, rather than the CLI writing it during a chat. Many old sessions also get re-stamped together within the same ~20-minute window, which looks like one batch sync rather than me opening each chat.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.212 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

The session content is never modified, only the file's modification time. So this looks like a display/ordering choice (sort by file mtime) interacting with sync rewrites. Reading the last message timestamp from the transcript instead would fix it.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗