[BUG] Desktop app resumes an older session; large session .jsonl files get mtime updated days after their last message

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 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?

On launch, the Claude Code desktop app (macOS) opens a session from ~2 weeks ago instead of the session I used the previous day. This has happened repeatedly over the past several days.

No data is lost — all session files are present in ~/.claude/projects/<slug>/. The problem is which session gets resumed.

While investigating, I found a possibly related anomaly: only the large session files have an mtime far in the future relative to their last message. The two small files have mtime ≈ last message. If session selection is based on file mtime, this would explain resuming the wrong session.

All timestamps below are UTC. last_msg = newest timestamp field inside the .jsonl; mtime = filesystem modification time.

| session id (prefix) | size | last_msg (inside file) | file mtime | drift |
|---|---:|---|---|---|
| 1b3adcf6 | 10.6 MB | 2026-08-20T12:55:45Z | 2026-08-20T12:55:45Z | none |
| 9631efdd | 0.2 MB | 2026-07-21T22:42:46Z | 2026-07-21T22:43:01Z | none |
| 4bd8e77e | 54.9 MB | 2026-07-10T13:22:22Z | 2026-08-12T14:13:40Z | +33 days |
| d15a95c5 | 108.9 MB | 2026-08-06T04:16:27Z | 2026-08-18T09:37:19Z | +12 days |

Pattern: only the two large files (54.9 MB, 108.9 MB) have drifted mtimes. Nothing in those conversations was written after their last_msg — I did not open or use them on Aug 12 / Aug 18.

The app opens d15a95c5, whose newest message is 2026-08-06 — i.e. the session with the most recent file mtime, not the most recent conversation.

What Should Happen?

Launching the desktop app should resume 1b3adcf6 — the session I used on 2026-08-19 (395 messages that day) and 2026-08-20, i.e. the session with the newest message timestamp.

Error Messages/Logs

$ ls -la ~/.claude/projects/<slug>/*.jsonl
(mtime, UTC)
2026-08-20 12:55   10.6 MB   1b3adcf6...jsonl
2026-08-18 09:37  108.9 MB   d15a95c5...jsonl
2026-08-12 14:13   54.9 MB   4bd8e77e...jsonl
2026-07-21 22:43    0.2 MB   9631efdd...jsonl

Newest message timestamp inside each file (UTC):
1b3adcf6  2026-08-20T12:55:45Z   <- mtime matches
9631efdd  2026-07-21T22:42:46Z   <- mtime matches
4bd8e77e  2026-07-10T13:22:22Z   <- mtime is 33 days later
d15a95c5  2026-08-06T04:16:27Z   <- mtime is 12 days later

No error message is shown. The app simply displays the wrong conversation.

Steps to Reproduce

  1. In one project directory, have several sessions, at least one of them large (>50 MB)
  2. Use the newest session on day N (in my case 2026-08-19, 395 messages that day)
  3. Quit the desktop app
  4. Relaunch the desktop app on day N+1
  5. An older session is shown instead of the one used on day N

Note: I could not find a way to force the mtime drift — it appears to happen on its
own to large session files (two of mine drifted, on 2026-08-12 and 2026-08-18, with no
action from me). So step 1 may need a session file that has already drifted.

Claude Model

_No response_

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.32885.1 (Claude desktop app, /Applications/Claude.app)

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

Platform: "Other" — I use the Claude desktop app with a Claude subscription, not the API / Bedrock / Vertex.
I am not using the CLI — only the desktop app. The "Terminal/Shell" field does not really apply.

The version above was read from the app bundle (/Applications/Claude.app), because claude --version is not available on this machine.

Note on the duplicate suggestions: I checked #88168, #75229 and #87335. None of them describes resuming the wrong session on launch, and none mentions the mtime drift on large session files, which is the part I think is the actual clue here.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗