Server-side session state regression: active sessions disappear from active views across mobile / web / desktop after GUI 1.10628.2 (embedded CLI 2.1.161) update on 2026-06-03

Summary

After the desktop GUI auto-update from 1.6608.2 → 1.10628.2 (which
downloaded embedded CLI 2.1.161) around 2026-06-03 ~20:17 local
(UTC+8), every session that was previously active has stopped appearing
in active views across all three client surfaces — mobile app, web
(claude.ai/code), and the desktop GUI. The sessions are not deleted
(they still appear in Recents lists and under Archived on mobile), but
they cannot be resumed, cannot receive messages, and produce no push
notifications.

Because the failure manifests identically across three independent
clients, the root cause is almost certainly server-side session state
corruption, not a client UI bug.

Affected versions and timeline

| When | Event |
|---|---|
| 2026-05-04 | Embedded CLI 2.1.128 published (last known-working CLI) |
| 2026-05-09 | Desktop GUI 1.6608.2 released (last known-working GUI) |
| 2026-06-02 17:38 UTC | CLI 2.1.161 published to npm |
| 2026-06-03 ~20:17 (UTC+8) | Desktop GUI auto-updated to 1.10628.2; embedded CLI auto-downloaded 2.1.161 |
| 2026-06-04 | Failure observed across mobile, web, and desktop |

Symptoms (cross-client)

Mobile app — Code tab

• Active sessions are absent from All and Completed views.
• All entries in All are labelled "Disconnected".
• Archived jumped to 20+ entries, all of which were active immediately

before the GUI update.

• Affected sessions cannot be opened to send a message; no push

notifications received.

Web — claude.ai/code

• The "Sessions" panel shows only entries with status Ready for review.
• No Running / In progress sessions are visible anywhere on the page.
• The Recents sidebar still lists the sessions (they were not deleted),

but their status field is stuck.

Desktop GUI

• Same set of sessions appears in lists but not as resumable / active.

Why this is server-side, not client

I rolled the desktop GUI back to 1.6608.2 (embedded CLI auto-downgraded
to 2.1.128), cleared the Squirrel ShipIt cache, and disabled
auto-update (SUEnableAutomaticChecks=0, SUAutomaticallyUpdate=0).
After rollback:

• The local Claude processes start and establish TCP :443 connections

to backend hosts (29.240.0.x, 160.79.104.10).

• **However, claude.ai/code in a browser and the mobile app continue

to show the same broken state.**

Since web and mobile read directly from the server-side session store
and are independent of which desktop client version is installed locally,
the rollback proves the corrupted state lives on the server. Whatever
migration / state transition shipped with the 1.10628.2 / 2.1.161
rollout wrote bad metadata that no client can correct from its side.

There are no relevant log lines mentioning archive / cleanup in
~/Library/Application Support/Claude/logs/main.log, which is also
consistent with the bad state being pushed from the server rather than
produced locally.

Expected behavior

• Sessions that were active prior to 2026-06-03 are restored to their

pre-upgrade status (active / in-progress).

• Mobile and web again show active sessions in active views.
• Push notifications and the ability to send messages into existing

sessions are restored.

Impact

• 20+ in-flight sessions inaccessible from mobile and web; cannot

continue work remotely.

• No mobile push notifications, breaking async workflow.
• Local rollback has no effect, so end users cannot self-recover —

server-side intervention is required.

Environment

• Platform: macOS (Apple Silicon)
• Desktop GUI before / after: \1.6608.2\ → \1.10628.2\ (currently rolled

back to \1.6608.2\)

• Embedded CLI before / after: \2.1.128\ → \2.1.161\ (currently back to

\2.1.128\, located at
\~/Library/Application Support/Claude/claude-code/<version>/\)

• Independent brew-installed \/opt/homebrew/bin/claude\ is \2.1.39\ and

is not involved in the desktop GUI workflow — the GUI invokes the
embedded CLI exclusively (via the \disclaimer\ helper).

Happy to provide my account identifier privately on request so the
affected sessions can be recovered server-side.