[BUG] Desktop Windows: sidebar pins never persist across app relaunch — pin-to-server sync fails, sidebar re-hydrates a stale pin set (repro on 1.21459.3.0 and 1.22209.0.0)

Claude Desktop (Windows): sidebar pins do not persist across app relaunch — pin actions never sync server-side; sidebar reverts to a stale pin set

Environment

• App: Claude Desktop for Windows, v1.22209.0.0 (bug also present on v1.21459.3.0 before updating)
• Install: official website MSIX (Get-AppxPackage → SignatureKind: Developer, path C:\Program Files\WindowsApps\Claude_1.22209.0.0_x64__pzs8sxrjxfjjc)
• OS: Windows 11 Home 10.0.26200
• Account setup: 3 login profiles used on this machine (Max plan); bug reproduced while staying on ONE profile the whole time (no sign-out involved)

Summary

Pinning a session in the sidebar appears to work (pin renders immediately), but the pin never persists. On every app relaunch the sidebar re-hydrates from the server-side session registry, which still contains an old pin set — all pins made since simply vanish. Local state (localStorage dframe-store → pinnedOrder) retains every pin the user made; the server-side list never picks them up.

Steps to reproduce (100% for this user, both versions)

1. Open Claude Desktop, stay on one login profile.
2. Open any session and pin it via the sidebar (pin renders in the Pinned section immediately).
3. Wait several minutes (rules out killed-before-sync).
4. Fully quit the app (tray → Quit) and reopen.
5. Result: the new pin is gone; the Pinned section shows the same stale set (4 entries, unchanged for days).

Evidence collected 2026-07-16

• Local vs server mismatch: localStorage dframe-store.pinnedOrder contains 60 pin ids including all newly-made pins (verified via direct leveldb read). After relaunch the sidebar renders only 4 — the same 4 every time.
• Per-session registry blobs (%APPDATA%\Claude\claude-code-sessions\<acct>\<org>\local_*.json) exist for every pinned session, isArchived: false, correct cliSessionIds — so the app wrote local state; only the server list is stale.
• Controlled A/B on v1.22209.0.0 (~21:00): pinned exactly one session ("SFX Mission Control Project"), waited, full quit + reopen → pin gone. Same behavior as pre-update.
• New observation on v1.22209: on first open (Home view) the Pinned section briefly shows a different pin set (long auto-generated titles, e.g. "Build AI-powered MCP for Smile-FX patient acquisition"); after clicking into a Code session the Pinned section swaps to the stale 4-entry set. Two different registries appear to be hydrating the same UI surface.
• Aggravating incident (v1.21459.3.0, same day): C:\ProgramData\Claude\Logs\cowork-service.log shows claude.exe dying abruptly (pipe EOF, no clean shutdown) at 14:41:42, 15:12:44, 15:52:26, each followed by relaunch. Two WER "HamLkd" (app-hang) buckets at 09:57/09:58. The user had pinned ~10 freshly-resumed sessions at 14:26–14:41; the 14:41:42 crash + relaunch reverted all of them. (The crashes may be a separate bug; included because the relaunch is what exposes the pin loss.)

Expected

A pin made in the sidebar persists across app relaunches (syncs to the account's server-side registry).

Actual

Pins render only for the current app run; every relaunch reverts to a stale server-side set. Effectively, pinning has been non-functional on this machine since at least 2026-07-16 (and pin loss after updates was previously observed 2026-06-10 and 2026-07-02).

Impact

Users who organize work via pinned sessions lose their workspace organization on every restart/update/crash. With frequent app crashes (see timestamps above) this compounds into repeated data-entry loss.

Notes

• Not profile confusion: reproduced start-to-finish on a single profile.
• Not local data loss: all pins recoverable from local pinnedOrder; the defect is the pin→server write (or server→sidebar hydrate) path.
• Related prior report from this machine: sidebar/remote-control issue anthropics/claude-code#76954.

Related (checked before filing — not duplicates)

• #71340 — pinned sessions dropping from the pinned area on web fleet view pagination. Different surface/mechanism (this report is Desktop Windows pin→server persistence across relaunch), but possibly the same underlying registry service.
• #76954 — prior report from this same machine (sessions bound to dead Remote Control owner); mentioned for environment context only.