[BUG] Desktop session silently stops syncing to the server after the first few messages (never recovers)

Environment

• Claude Code desktop app, version 2.1.219
• Windows 11 Pro (10.0.26200)
• 5 desktop sessions running in parallel, same machine, same working directory
• Also using the Claude mobile app and claude.ai/code in a browser

Summary

One of five desktop sessions stopped syncing to the server after its first few messages. The local session kept working normally for two more days, but on claude.ai/code that session still shows only the opening exchange, under its original auto-generated title. Sending new messages does not resume syncing.

Details

| | Local (desktop app) | Server (claude.ai/code) |
|------------------|------------------------------|----------------------------------|
| State | Healthy, used for 2 days | Only the first few messages |
| Transcript file | ~10.7 MB | (as above) |
| Title | Manually renamed | Original auto-generated title |

The other four sessions — same machine, same working directory, same app version, started within seconds of each other — sync correctly, including same-day messages.

What we verified

• Status filter Active / Archived / All on claude.ai/code: the session does not exist anywhere under its new name
• The frozen session is present under its original auto-generated title, with only the opening exchange
• Sending a new message to that session (and the session processing it) does not resume syncing
• Local data is intact; nothing was lost locally

Related observation: renames do not propagate

Renaming a session in the desktop app does not update the title on the server. This reproduces on healthy sessions too — a session whose content syncs correctly still shows its old title on claude.ai/code. This makes it hard to find the intended session from mobile or a browser.

Impact

From any surface that reads server state (mobile app, another machine's browser), the session's current content is unreachable — it looks like the thread disappeared. We nearly rebuilt several healthy sessions from scratch before confirming in a browser that their data was fine.

Note (possible confound)

Shortly before this was noticed, this account ran the bulk "delete sessions stored by Anthropic" action from settings, and later deleted a number of old sessions via DELETE /v1/sessions/{id}. The frozen session was not among the deletion targets and still exists server-side under its old title, so we don't believe deletion is the cause — flagging it in case it is relevant.

Repro

We cannot give reliable repro steps. What we know:

1. Run several desktop sessions in parallel in the same working directory
2. Use them over a couple of days
3. Compare the desktop sidebar against claude.ai/code — one session's server copy may be stuck at its initial state