[BUG] Desktop "Code" sessions show "No messages yet" — cliSessionId missing/nulled on every launch, and sending a new message silently forks a disconnected session

[BUG] Desktop "Code" sessions show "No messages yet" — cliSessionId missing/nulled on every launch, and sending a new message silently forks a disconnected session

Environment

• Claude Desktop app version: 1.17377.2 (macOS)
• Bundled Claude Code CLI version: 2.1.197 / 2.1.198
• Platform: macOS (Apple Silicon)
• Account: paid Pro plan

Summary

Multiple "Code" tab sessions in Claude Desktop show "No messages yet" in the sidebar, even though the underlying conversation data is fully intact on disk (~/.claude/projects/<escaped-cwd>/<uuid>.jsonl, hundreds of real turns, sometimes hundreds of KB to several MB per file).

Root cause traced to: the session's metadata file at
~/Library/Application Support/Claude/claude-code-sessions/<accountId>/<orgId>/local_<uuid>.json
is missing (or has null) the cliSessionId field that links the Desktop UI "tile" to its real underlying CLI transcript UUID. Without this field, Desktop cannot locate the transcript and renders the tile as empty.

This appears to match / overlap with issue #63082, but I want to document a fuller reproduction plus an additional, more destructive side effect not covered there.

Evidence

1. Metadata comparison (working vs broken sessions)

Comparing the JSON keys of a working session's metadata file against a broken one:

• Working session: has cliSessionId: "<uuid>" pointing to a real .jsonl file.
• Broken session: cliSessionId key is either absent or null.

In my case, out of ~12 interactive Code-tab sessions, 7 were missing cliSessionId while metadata (completedTurns, lastActivityAt) confirmed real activity (61–743 completed turns each) — the transcript files themselves were found fully intact under ~/.claude/projects/.

2. The correct link can be recovered from app logs

When Desktop attempts a background MCP sync for a broken session, it leaks the real underlying session ID in ~/Library/Logs/Claude/main.log:

[CCD] ... Error: Claude Code returned an error result: No conversation found with session ID: <real-uuid>

This <real-uuid> matches an existing, real .jsonl file on disk with full conversation content — confirming the data is 100% intact, only the link is broken.

3. Manual fix does not survive app restart (startup scanner re-nulls the field)

Steps taken:

1. Manually added "cliSessionId": "<real-uuid>" to the broken session's local local_<uuid>.json file.
2. Fully quit Claude Desktop (Cmd+Q) and relaunched.
3. Clicked the session tile once (per the workaround suggested in #63082).

Result: the field was silently reverted back to absent/null by the app itself during startup, before the tile was even clicked. Confirmed by:

• File mtime updated to the exact relaunch timestamp.
• Fresh main.log entries for that exact sessionId at the same timestamp (LocalSessions.replaceEnabledMcpTools, LocalSessions.replaceRemoteMcpServers, LocalSessions.startShellPty), indicating an active startup scanner processed and reset the session.

This reproduces the exact "not fully deterministic... re-nullified on a later launch" behavior described in #63082, on a fresh, independent case.

4. New finding: sending a message into a broken session silently forks a disconnected session (data-loss risk)

This is the more concerning part, not fully covered by existing issues I found:

1. Session shows "No messages yet" (or, in one case, stale cached content from before an error).
2. User sends a new message. First attempt fails with a visible in-app error: Claude couldn't process that message — No conversation found with session ID: <some-uuid>.
3. User sends another message (e.g. "are you there?"). This one succeeds and gets a normal reply.
4. The assistant's own reply confirms it has no access to the prior history — e.g. responding "In this session I only see two messages from you: X and Y" — even while the UI still visually displays old cached messages above (a stale render, not live state).
5. On reopening the app/session, the old cached display disappears entirely, and only the new orphaned 2-message exchange persists.
6. Checking the metadata file afterward shows Desktop auto-populated a brand new cliSessionId pointing to a newly created, nearly-empty session — completely disconnected from the original (still fully intact, but now orphaned) transcript.

Impact: a user who doesn't realize this is happening can send a message into what looks like a continuation of an old conversation, get a plausible-sounding reply, and permanently lose the apparent continuity with their old history from the Desktop UI's perspective — even though the old data technically still exists on disk under a different, now-unreferenced UUID. This is a silent data-integrity/UX issue, not just a display bug.

Steps to Reproduce

1. Have a Claude Desktop Code-tab session with substantial history accumulate over several days/restarts.
2. At some point (app update, restart, or unknown trigger) the sidebar tile begins showing "No messages yet" while completedTurns in its metadata file remains non-zero.
3. Attempt the manual cliSessionId fix from #63082 — observe it does not survive a full app restart.
4. Attempt to send a new message into the broken session — observe the silent fork described above.

Requested Fix

1. Make the cliSessionId link persist reliably (fix the startup scanner logic that nulls it).
2. When a session's transcript can't be located, do not silently create a new orphaned session on the next message — at minimum, warn the user explicitly ("this will start a new conversation, unable to locate previous history") before accepting new input into a tile with broken linkage.

Related issues

• #63082 — startup scanner deletes cliSessionId (closest match, confirms the reset behavior)
• #45710 — missing migration to new claude-code-sessions storage format
• #61532 — similar symptom, closed as "unrecoverable", but in my case the data was recoverable directly from ~/.claude/projects/
• #26452 — general "session disappeared after restart"
• #54187 — "No messages yet" after Desktop update

Happy to provide additional log excerpts or metadata file examples (redacted) if useful.