Remote Control: unarchived session never reactivates - every dispatch spawns a NEW session uuid and dies instantly on all environments (Windows)

Summary

A remote session created from claude.ai/code on a Windows Remote Control environment was archived from the claude.ai UI (see the /exit note below — archiving is effectively the only "close" affordance) and then unarchived. Sending new messages never revives it: every activation attempt spawns a local process that dies within ~1s, on every online environment of the machine, with a freshly generated session uuid each time — while a plain local claude -p --resume <original-uuid> of the very same session works perfectly.

Environment

• Claude Code 2.1.220, Windows 11 Pro (build 26200)
• Auth: claude.ai subscription; server started via claude remote-control in a trusted project folder
• Session: session_01Nj6dExviymNdHeTwQT6gq2, original local transcript uuid b0cb6f8d-503e-4b41-a931-0229ac87718c under the trusted cwd's project dir

Timeline / repro (all today)

1. Session created from claude.ai/code on the machine's Remote Control environment; spawned in the trusted folder and ran normally (~3h, real content).
2. User asked the session (in-conversation) to close itself; it replied it cannot, and suggested typing /exit. But slash commands are not available from the claude.ai mobile UI (and per the user, apparently not from the desktop web UI either) — so the user archived the session from the UI instead, while it was idle. Side gap: the suggestion itself is technically sound — the session runs in a CLI where /exit is a real command — but the remote mobile/web UI layer doesn't surface slash-command input, so archiving is the only close affordance it actually offers.
3. Later: unarchived it and sent new messages from the web UI.
4. Observed on each activation attempt (4+ attempts across ~10 minutes):

• The RC server window keeps showing 0 active sessions (no "Session failed" line for these).
• A fresh empty temp dir appears under %LOCALAPPDATA%\Temp\claude\<encoded-trusted-cwd>\<uuid> — a different, freshly generated uuid on every attempt (4 distinct uuids observed), never the original session's uuid.
• The same happens in parallel under the home-dir project for the desktop-app environment — that one is expected to die (the desktop app registers an environment whose cwd is the untrusted home dir, so its spawns exit at the trust prompt), but the trusted-cwd attempts die the same way.
• Each attempt leaves a ~/.claude/backups/.claude.json.backup.<ts> (so the spawn gets far enough to touch config) and writes no transcript.

1. A claude.ai "Sign in again to verify your device" re-auth was completed in the browser mid-investigation — no change.
2. Control tests:

• Creating a new session on the same RC environment works (verified earlier the same day).
• claude -p --resume b0cb6f8d-... locally, same machine, same auth: answers normally, exit code 0. The transcript is intact. (This also rules out #79662 for this case.)

Expected

Unarchiving an exited session and sending a message should re-attach to the original session (resume its transcript on its environment), or surface a visible error in claude.ai/code. Instead the message just sits there, the dispatch silently retries with fresh session uuids that have no local state, and the user sees a session that "won't come back."

Possibly related

• A similar silent multi-environment retry pattern was diagnosed on this machine earlier the same day with a pending, never-started session: claude.ai re-attaches it whenever any environment comes online and the spawn dies at the desktop-app environment's untrusted home cwd. Not filed as a separate issue.
• #79662 — ruled out here; local Fable resume works.