Desktop: session record lost — clicking the chat opens a NEW empty session that inherits its title and a different cwd

Summary

A session's entry disappeared from the Claude Code desktop app's session list. Clicking what appeared to be that chat opened a brand-new empty session that inherited the missing chat's title but none of its conversation. The next message typed landed in the blank session, which had no context and a different working directory — silently. The user believed they were still in their existing chat.

The original transcript was fully intact on disk the whole time. Only the app-side session record was lost.

Environment

• Claude Code desktop app: 1.22209.3
• Claude Code CLI: 2.1.197
• macOS 26.5.2 (Apple Silicon)

What happened

1. A long-running session ("Pick up tasks skill lookup") had been working for ~2 days inside a git worktree at ~/gitroot/<project>/.claude/worktrees/task-111-.../. Its transcript lives at:

~/.claude/projects/-Users-<user>-gitroot-<project>--claude-worktrees-task-111-.../1c4cc90f-....jsonl
1,284 lines, ~2 MB, spanning 2026-07-30T20:14:34Z → 2026-08-01T03:38:49Z. The final assistant message asks the user a question and waits for an answer.

1. Hours later the user opened that chat from the app's session list and replied "merge it".
2. That message went into a new session (6d96e79c-...), created at 2026-08-01T21:23:29Z, with:

• cwd = the parent repo, not the worktree the original session was running in
• a custom-title record of "Pick up tasks skill lookup" — the missing chat's title
• zero prior conversation content
• no resume / parent-session / fork pointer of any kind linking it to the original

1. The assistant in the new session correctly reported "there is no prior work in this chat" — which read to the user as the assistant having lost or forgotten their conversation. Several rounds were wasted before the original transcript was located on disk.

Evidence that the app-side record (not the transcript) was lost

Enumerating all sessions via the session-management API (list_sessions, include_archived: true, 60 entries) shows that every other chat has a registry entry whose lastActivityAt matches its transcript's final timestamp. Examples:

| registry entry | lastActivityAt | transcript file | transcript last timestamp |
|---|---|---|---|
| "Tab icons for navigation" | 2026-07-30T20:57:53.457Z | d59b4fad-...jsonl | 2026-07-30T20:57:53.439Z |
| "UI bugs post 110" | 2026-08-01T21:22:37.814Z | b7a57c13-...jsonl | matches |

There is no registry entry anywhere — active or archived — with lastActivityAt near 2026-08-01T03:38:49Z, the task-111 chat's final timestamp. Its record is simply absent, while its .jsonl sits intact on disk.

Also note: the app's sessionId and the transcript filename UUID are different identifiers (e.g. registry local_a793c13d-... ↔ transcript b7a57c13-...), so there is no way for a user — or an assistant asked "what happened to my chat" — to map one to the other from the app UI. That materially worsens recovery.

Impact

• Silent context loss. Nothing warns the user that the chat they clicked is not the chat they get. The inherited title actively disguises it.
• The new session gets a different working directory (parent repo instead of the worktree). For worktree-based workflows this is dangerous: a follow-up instruction like "merge it" or "commit this" now executes against the wrong checkout.
• The assistant in the new session cannot diagnose it, because from inside that session the state is indistinguishable from a genuinely new chat.

Expected behavior

Any of:

1. Don't lose the session record. (root fix)
2. If a session record is missing but its transcript exists on disk, rehydrate from the transcript rather than silently minting an empty session.
3. If a new session is created, do not inherit the missing chat's title, and surface a visible notice ("previous session could not be restored — starting a new chat").
4. Never silently substitute a different cwd than the session the user clicked.

Repro

Not deterministically reproduced — the trigger for the registry entry's disappearance is unknown. Reported because the on-disk evidence is unambiguous about the failure mode and the diagnostic table above should make the app-side path identifiable. Happy to supply the (redacted) transcript metadata or session UUIDs if useful.