Desktop app: session history silently lost mid-conversation when CLI resume session ID is stale

Summary

A long-running local session (bound to a git repo, with an open PR shown as a chip in the composer — repo/branch/PR/CI status) hit a resume failure mid-conversation. The UI surfaced a generic "Claude couldn't process that message" error, and immediately after, a "Session history unavailable — This session's conversation history is no longer on disk" banner appeared, offering only "Start fresh." All prior conversation context for that session was lost.

Environment

• Claude desktop app (macOS / Darwin)
• Bundled Claude Code CLI version: 2.1.202
• Session type: local session in a project folder, git-worktree-based task, with a GitHub PR bound to the session (PR chip visible at the bottom of the composer)

What happened (from app logs, ~/Library/Logs/Claude/main.log)

1. Session had been active for several hours with an open PR bound to it.
2. On the next message, the app tried to resume the local session via a cached CLI session ID:

``
Session local_4fe45503-437a-4a67-bf90-456a270e6516 query error: Claude Code returned an error result: No conversation found with session ID: 9c1c2f06-6979-42d9-bd45-07f8c582873f
at pF.readMessages (app:///.vite/build/index.js:918:20531)
``

1. The app's cycle-health handler cleared the stale resume handle, with no archived fallback available:

``
[warn] [CCD CycleHealth] local_4fe45503-437a-4a67-bf90-456a270e6516 cli_execution_error (error_during_execution): No conversation found with session ID: 9c1c2f06-6979-42d9-bd45-07f8c582873f
[info] [CCD] clearStaleResumeHandle session=local_4fe45503-437a-4a67-bf90-456a270e6516 reason=cli_resume_not_found_result dropping cliSessionId=9c1c2f06-6979-42d9-bd45-07f8c582873f unarchivedCliSessionId=undefined
``

1. This surfaced in the UI as "Claude couldn't process that message" (Try again / View details), and subsequently as "Session history unavailable... sending your message will start a fresh session in this folder."
2. Sentry event ID for this occurrence: b0350d12c9d249dd8e2ef3039bc900b7

Impact

For long sessions tied to a git worktree/PR (i.e. exactly the kind of session that accumulates a lot of task-specific context), a stale/evicted CLI session ID results in total, unrecoverable loss of conversation history, with no fallback other than "Start fresh." There's no visible retry-from-archive path (unarchivedCliSessionId=undefined suggests a fallback mechanism exists but had nothing to fall back to here).

Question for the team

• Is the on-disk CLI transcript itself actually gone, or just the app's cached resume handle pointing to it? If the transcript still exists on disk, could resume fall back to locating it by cwd/session metadata instead of only trusting a single cached cliSessionId?
• At minimum, surfacing why history became unavailable (stale handle vs. truly missing transcript) would help users trust that "Start fresh" is actually necessary.