[BUG] Recent sessions list shows stale/live-changing timestamps — items appear out of order or vanish entirely

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?

The "Recent" sessions list is unreliable in three distinct ways, confirmed with concrete data via the ccd_session_mgmt MCP tools (list_sessions/get_session) during a single investigation session:

1. A session's lastActivityAt freezes after its linked PR is merged, even when the user keeps using that same session afterward. Example: session titled "GED finalização e Docker setup" (PR #269, merged) returned lastActivityAt = 2026-07-20T07:51:24Z across two separate queries, but the user confirms working in that exact session as late as 2026-07-22 (~2am), leaving a background task running. The timestamp never moved.
2. A session's lastActivityAt can change between two consecutive API calls seconds apart, with no user interaction in between — likely a background/autonomous task updating it live. Example: session "Coleta de modelos de documentos Zohan" returned lastActivityAt = 2026-07-19T17:48:42Z on one call and 2026-07-22T11:47:47Z (a ~3 day jump) on the next call moments later.
3. A session can disappear from the list entirely — not even archived. The user did real work in a session titled "Skills jurídicas 21 07 26" (2026-07-21), but it does not appear anywhere in the 50 most recent sessions (list_sessions with include_archived: true), archived or not.

Additional evidence from the same investigation: two other sessions were rendered in the wrong chronological order relative to their own reported lastActivityAt values (a session from 2026-07-17 appeared sandwiched between sessions from 2026-07-20/21; two sessions from 2026-07-19 appeared in reverse order relative to each other).
Impact: users lose track of active work sessions regularly, especially in projects that run long-lived/autonomous background tasks. They have to guess which session a piece of work landed in, or reopen several until they find it. Renaming a session also sometimes fails to persist, compounding the problem.
Request: investigate why lastActivityAt (a) stops updating after a linked PR merges despite continued use of the same session, and (b) can update asynchronously/inconsistently between near-simultaneous reads for sessions with background activity — and ensure "Recent" ordering reflects true current activity, not a stale or divergent snapshot.

its being happing in all versions i have update of claude. old problem.

What Should Happen?

The "Recent" sessions list should order sessions by their true, current last-activity time, and every session where the user did real work should remain visible (or be properly archived) — it should never silently vanish, and its timestamp should never freeze at a stale value while the user keeps using it.

Error Messages/Logs

No error message or crash — this is a silent data-consistency issue in session metadata, not a visible error. See "Steps to Reproduce" for the concrete evidence gathered.

Steps to Reproduce

This is hard to give as a fully minimal repro since it depends on specific session states, but here's exactly how it was surfaced:

1. Have a session whose work was completed via a linked GitHub PR that later gets merged (Claude Code's PR integration), then keep interacting in that SAME session afterward.
2. Have a separate session in a project that runs long-lived/autonomous background tasks (e.g. an overnight agent loop).
3. Query the session list twice in a row, a few seconds apart (via the sidebar, or the ccd_session_mgmt MCP's list_sessions), while doing nothing else in between.
4. Observe:

a. The PR-merged session's lastActivityAt stays frozen at merge time, even though the user used it again 2 days later.
b. The background-task session's lastActivityAt differs between the two near-simultaneous reads (observed a ~3 day jump in seconds).
c. A session the user confirms working in recently does not appear anywhere in the list, even with archived sessions included.

Concrete data from one investigation session (IDs/timestamps available on request):

• Session "GED finalização e Docker setup" (PR #269, merged): lastActivityAt stuck at 2026-07-20T07:51:24Z across 2 queries, despite confirmed use on 2026-07-22.
• Session "Coleta de modelos de documentos Zohan": lastActivityAt = 2026-07-19T17:48:42Z on one query, then 2026-07-22T11:47:47Z moments later on the same session, no user action in between.
• Session "Skills jurídicas 21 07 26" (real work done 2026-07-21): absent from the 50 most recent sessions including archived.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.158

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related but distinct issue: #20896 (sessions that appear but fail to load with "Failed to load session") — not a duplicate, different failure mode.