Cloud/worktree sessions with meaningful auto-generated titles show "No messages yet" — transcript genuinely empty server-side, not a render bug

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?

Several Code tab sessions in my sidebar have a title but open to an empty right-hand pane reading "No messages yet". Using the ccd_session_mgmt MCP tools available to Claude in-session (list_sessions / list_events), I confirmed this is not a client-side render failure: the backend itself reports "showing 0 of 0 messages" for these sessions — the transcript is genuinely absent server-side, not just failing to load/render.

This looks related to #93860 but is a distinct case: that issue describes never-started local macOS sessions that get a generic "<hostname>-local-x-y" sidebar name and a 267-byte bridge-session-only file, i.e. sessions where no conversation ever began. Mine are different in every relevant way:

• All affected sessions have meaningful, specific, conversation-derived titles (e.g. "Composio installation", "Zigbee yard spots sophistication", "Mahnatar CN105 commissioning & usage") — titles like this are only generated after real exchanges happen, implying these sessions DID have content at some point.
• All 18 affected sessions have cwd rooted under a remote/cloud path (/root/homeassistant or a .claude/worktrees/... subdirectory under it) — i.e. cloud/background-agent sessions, not local Desktop sessions opened-and-abandoned.
• This is also not the "data intact but UI fails to load it" symptom described in #84858, #89873, and #63025 — I have no way to inspect the raw jsonl directly, but the same backend query that returns full transcripts for my other sessions (one had 785 messages, another 710) returns literally zero for these 18.

Also notable: it is NOT universal to cloud/worktree sessions. Many other sessions with the same /root/homeassistant-rooted cwd pattern have full, intact transcripts (up to 785 messages). Only a subset are affected.

What Should Happen?

A sidebar entry that carries a real, conversation-derived title should always open to its full transcript. If a session's transcript was never persisted (or was lost) server-side, it should either not appear in the sidebar at all, or should be visibly flagged as broken/unrecoverable rather than silently rendering as a normal-looking session with "No messages yet".

Error Messages/Logs

Steps to Reproduce

1. Use the Code tab and run background/cloud agent sessions against a remote worktree (in my case, repeated sessions rooted at /root/homeassistant and /root/homeassistant/.claude/worktrees/<slug>) over a period of days.
2. Periodically check the sidebar — most sessions show their real title and open normally with full history.
3. Click on a subset of sessions whose titles look completely normal and conversation-specific (not generic) — the right-hand pane shows only "No messages yet".
4. From another Code tab session with the ccd_session_mgmt MCP tools available, call list_sessions(include_archived: true) to confirm the session record exists with metadata (title, cwd, branch, lastActivityAt), then call list_events(session_id: "<the affected session>") — the response is "showing 0 of 0 messages" / "(no messages)", confirming the transcript is empty server-side, not just failing to render client-side.
5. Compare against a known-good session from the same cwd family via the same list_events call — it returns the full transcript (I confirmed transcripts up to 785 and 710 messages for other sessions with the same cwd root), showing the backend query itself works correctly and the difference is specific to the affected session records.

I found 18 affected sessions this way in one account; a full list of titles and timestamps is in the "Additional Information" section below.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.211 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Terminal/Shell "Other": this is the Desktop app's Code tab (GUI session view), not a terminal emulator.

Related but distinct issue: #93860 describes never-started local macOS sessions with generic "<hostname>-local-x-y" names and 267-byte bridge-session-only files — sessions where no conversation ever began. This report is about sessions that clearly DID have real conversations (specific, topic-derived titles) whose transcripts are now empty server-side. Possibly the same underlying persistence mechanism, possibly not — flagging the distinction in case it helps triage.

Full list of the 18 affected sessions found in one account (title — last activity, all cwd rooted at /root/homeassistant or a .claude/worktrees/<slug> subdirectory under it):

• Crashboards session recovery — 2026-09-21T14:46:14.765Z (cwd: /root/homeassistant)
• Stremio manifest configuration — 2026-09-21T00:39:46.824Z (cwd: .../worktrees/stremio-manifest-config-29bebe)
• Google Tasks Home Assistant integration — 2026-09-19T16:28:31.202Z (cwd: .../worktrees/google-tasks-home-assistant-a6bab1)
• Guest 1-3 blinds automation — 2026-09-18T17:33:10.126Z (cwd: .../worktrees/guest-blinds-automation-3fe8e2)
• NUC unexpected reboot at 3am — 2026-09-16T15:36:44.938Z (cwd: .../worktrees/nuc-unexpected-reboot-c97c02)
• Rename Ikea belresa remote to aew — 2026-09-13T17:35:59.813Z (cwd: .../worktrees/rename-belresa-remote-aew-901675)
• IKEA BILRESA remote commissioning — 2026-09-13T17:35:58.302Z (cwd: .../worktrees/ikea-bilresa-remote-8522c3)
• Mahnatar CN105 commissioning & usage — 2026-09-13T17:35:58.531Z (cwd: .../worktrees/mahnatar-cn105-enclosure-print-d4ea1e)
• matter setup — 2026-09-12T21:02:54.077Z (cwd: .../worktrees/device-log-diagnostics-d7318b)
• Zigbee yard spots sophistication — 2026-09-12T07:45:35.074Z (cwd: .../worktrees/zigbee-yard-lights-dropout-047582)
• Logging vs announcing zones clarification — 2026-09-12T07:45:22.947Z (cwd: .../worktrees/logging-announcing-zones-bf2ce3)
• "Local" & Fusion MCP — 2026-09-12T07:44:55.549Z (cwd: /root/homeassistant)
• Flight logging cache date formatting — 2026-09-12T07:44:31.350Z (cwd: .../worktrees/flight-cache-date-format-2de04d)
• kitchen downlights automation (claude) — 2026-09-12T06:33:26.987Z (cwd: .../worktrees/echo-show-kitchen-presence-e44abd)
• Drops & Recoveries section layout — 2026-09-12T06:33:26.463Z (cwd: .../worktrees/drops-recoveries-layout-199b6c)
• Enabled false meaning — 2026-09-12T00:38:16.394Z (cwd: .../worktrees/enabled-false-meaning-2ea898)
• ev V2H plus water heater alarm automation logic — 2026-09-11T18:32:40.785Z (cwd: .../worktrees/water-heater-alarm-logic-6bff71)
• Composio installation — 2026-09-02T01:38:30.927Z (cwd: .../worktrees/composio-installation-5e74b4)

Note: several of these share near-identical creation timestamps down to the same second, in small clusters (e.g. three sessions at 2026-09-13T17:35:58–59, several within the same minute around 2026-09-12T07:44–07:45). I want to flag explicitly that I do NOT believe this reflects deliberate parallel/simultaneous session spawning on my end — I'm a single user working one session at a time. If anything, that clustering is itself a symptom worth investigating (e.g. several background/cloud sessions being provisioned or torn down together by the app), not a cause I introduced. Please don't over-weight it as "user ran many parallel sessions" — treat it as an observation about the failure mode, not an explanation.