[BUG] Desktop session reset and vanished from list/archive after clicking a Claude-generated link — data still intact on Android

### What's Wrong?

Organization ID: fab770b3-4d45-460a-bdec-1a6f8992408b

Plan: Pro

⚠️ CRITICAL — READ BEFORE ANY FIX ATTEMPT

The Android app still holds the only intact copy of this session's full history. Any fix, sync, or account-reconciliation process MUST NOT overwrite, delete, or resync the Android app's local/session data. Back up and preserve the Android side before touching anything server-side.

Summary

Clicking a link Claude generated inside a desktop session (Code tab) triggered a forced re-authentication. After re-login, the affected conversation session no longer appeared in the desktop app's session list or archive.

generated link:
https://claude.ai/code/session_01MWvvLNMPDKtTGzEzyCZ6mJ

Time of occurrence: ~11:30 AM JST (UTC+9), September 19, 2026

Hard evidence from Account → Active Sessions (same org ID for both devices):

DeviceCreatedLast updatedClaude Desktop (current)2026-09-19 11:49 JST2026-09-19 11:49 JSTAndroid2026-09-17 11:58 JST2026-09-19 10:13 JST

The Android device session has been continuous since Sep 17, never logged out, never re-authenticated. Same organization ID confirms this is one account, not a mismatch between accounts.

Conclusion: the conversation data is intact server-side (visible via Android). The desktop app's device session was invalidated by the link-triggered re-auth and is now failing to reload the account's existing conversation sessions.

What I checked

list_sessions (including archived) from a separate desktop session returns zero sessions for this account.
Local session storage (.claude/projects) on the desktop machine shows no trace of the affected session's files.
Android app displays the session's full history up to the reset point, uninterrupted.
Additional troubleshooting already performed: after noticing the session was missing, signed out of Claude on desktop, restarted the PC, and signed back in. This is almost certainly what produced the "Claude Desktop" device-session entry created at 11:49 JST (shortly after the ~11:30 JST incident). The missing session did not reappear even after this full sign-out + OS restart + fresh sign-in, which rules out local application cache as the cause — the issue is server-side (the account's existing conversation sessions aren't being linked to the new desktop device session), not a client-side caching problem.

### What Should Happen?

1.Do not touch or resync the Android app's local session/account state until the desktop-side issue is understood.

2.Investigate why the link-triggered re-auth invalidated the prior desktop device session and created a new one (11:49 JST) that can't see the account's prior conversation sessions.

3.Reconnect the desktop app's account to its existing conversation session list (same result Android already shows).

4.Fix the root cause: a link click should never force a full re-authentication that orphans the device's session state.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. Open the Claude desktop app (Code tab) and work in an active session.
2. Have Claude output a link in its response (exact link type not confirmed — possibly an Artifact link; type of content that generated the link is unknown).
3. Click the link.
4. Observed: the current session is immediately force-logged-out and a re-authentication/login prompt appears.
5. Sign back in.
6. Check the session list and the archive.

Result: the session that was active when the link was clicked no longer appears in either the session list or the archive on the desktop app, even after signing out completely, restarting the PC, and signing back in.

Note: I could not reproduce this on demand — it happened once, unexpectedly, during normal use. I don't know which specific link or link type triggers it, so I can't confirm exact reproduction steps beyond what's described above.

### Claude Model

None

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.2553.1

### Platform

Other

### Operating System

Windows

### Terminal/Shell

PowerShell

### Additional Information

Two process-level concerns, separate from the bug itself:

1.Non-English users are structurally disadvantaged in this support flow. Filing this required navigating an English-only GitHub issue form, after GitHub itself temporarily blocked signup from my network. For a product used globally, the path to reporting a serious bug (data/account issue) should not require fluency in English or a GitHub account.

2.Apology-first responses without concrete action ring hollow, especially across cultural contexts. In interactions with Claude around this incident, expressions of concern were not consistently paired with verifiable, concrete steps — repeated "I'm sorry, but I can't help with that" without an actual path forward reads as deflection rather than resolution, particularly in contexts (like ours) where an apology is expected to be backed by demonstrated effort, not just stated regret. I'd ask that any process improvement here include not just the bug fix, but how Claude is expected to escalate/act when it identifies that a user is experiencing real data-loss risk.

No repository files or tests are named; start by reviewing the link-triggered re-authentication and session-list behavior described here while preserving the Android copy. Done means the existing sessions reappear on desktop without changing Android data, and clicking the link no longer orphans the desktop session.

Written by the indexing model from the issue text.