[BUG] VS Code extension: remote session from another machine shows "Couldn't load earlier messages" / "New messages start a new conversation", and each sent message silently forks a NEW local session

Same failure on a single machine with the default config dir, which answers the
"untested whether the default ~/.claude config dir is also affected" note in the report:
it is.

Environment

• Claude Code CLI 2.1.261, VS Code extension anthropic.claude-code 2.1.261 (win32-x64)
• Windows 11 Home 10.0.26200
• CLAUDE_CONFIG_DIR unset — default ~/.claude
• Single machine, single VS Code install. No second machine involved.

What differs from the original report

The sessions that fail here were never remote sessions at all. They are ordinary local
conversations created days-to-weeks before Remote Control was ever enabled, with no
server-side counterpart to attach to. So the failure isn't limited to "extension fails to
re-attach to a session started elsewhere" — once Remote Control is active, any
pre-existing local session opened from the history droplist fails the same way.

That suggests the fallback path is unconditional: the extension mints a fresh bridge for
whatever it opens, rather than only doing so after a remote attach attempt fails.

Symptom

The droplist lists sessions with correct titles. Selecting one renders a blank chat with
"Couldn't load this conversation earlier messages. New messages start a new conversation."
and "Remote Control is active" beneath it. The title then displays as "Untitled".

The split is informative: titles resolve, bodies don't. The extension reads the title
from the local .jsonl (which is why the droplist looks healthy) but delegates the message
body to the bridge, which has nothing.

Transcript forensics — same lastSequenceNum: 0 signature

All four local sessions in the affected workspace, ~/.claude/projects/X--dev/:

| session | entrypoint | bridge | lastSequenceNum |
|---|---|---|---|
| 4b9c4644 | claude-vscode | none | — |
| 57b6c090 | claude-desktop | cse_01NyYoVxKjVejX2DwKk4j1up | 0 |
| 58ecd281 | cli, claude-vscode | cse_0136UewYjtLfAKA9befsB54r | 0 |
| 9040a6cf | claude-desktop | cse_01G95LziXH1FDj1kuAtqUH7j | 0 |

Every bridge-session record carries "lastSequenceNum": 0 — the bridge replays nothing.
~/.claude.json accumulated four replBridgePlaceholders entries (cse_…) over the course
of the failed attempts.

Two clarifications that may narrow the diagnosis

1. No on-disk corruption. Despite the UI showing "Untitled", the real values survive in

the transcript — {"type":"custom-title","customTitle":"Passkey system limitations",…}
is still present and unmodified. "Untitled" is a UI placeholder for the empty bridged
conversation, not a write. The original report doesn't claim otherwise, but it's worth
recording that the local file is not damaged by a failed open.

1. The silent fork requires actually sending a message. No zombie sessions were created

here — the workspace still holds exactly 4 transcripts — because the failed load was
observed without sending anything afterward. This is consistent with the original
report's step 4 and bounds it: opening alone appends bridge/title metadata but creates
no new session; the fork happens on send.

Workaround

claude --resume <session-id> from the CLI loads full history correctly, bypassing the
bridge. Turning Remote Control off restores the extension's history droplist.

Follow-up to my earlier comment, same machine (CLI + extension 2.1.261, Windows 11,
default ~/.claude config dir, single machine). The silent fork reproduces here too,
so it is not specific to a custom CLAUDE_CONFIG_DIR or to the cross-machine case.

Reproduced fork, with timestamps

Two sessions were created in the OblivionRemastered_ItemClone project folder during the
Remote Control window:

| session | created | size | content |
|---|---|---|---|
| 61c0b757 | 14:50:21 | 221 B | custom-title + mode only — zero messages |
| 14a42a99 | 14:56:12 | 231 KB | 2 user records, 0 assistant |

14a42a99's first user record, at 2026-09-05T19:56:12Z:

"I just got a new indicator in the Claude Code VS Code plugin suggesting that I enable Remote Control, but when I did this I suddenly lost all of my se…"

Its second and final user record is [Request interrupted by user]. The message never got
a reply in that session.

82 seconds later, at 2026-09-05T19:57:34Z, that same opening message began session
9040a6cf in a different project folder (X--dev), where it ran normally. So one
typed message produced a dead session in one project folder and a live one in another.

The forks inherit a title, which is what makes the droplist misleading

Both zombies carry {"type":"custom-title","customTitle":"Handoff review: Oblivion
Remastered item clone"} — a title belonging to that workspace's earlier work. The result
in the droplist is two entries with an identical, plausible-looking recent title holding 0
and 2 messages, while the session with the actual work (427941d4, 325 user / 591
assistant) sits under an unrelated older title. To the user this reads as "my recent
sessions are gone" even though nothing was lost.

Partial workaround, and one that does NOT work

• Setting remoteControlAtStartup: false restores sessions in the extension **only if they

were never opened while Remote Control was active**. Sessions touched during the RC
window still render blank afterwards — now without the "Remote Control is active" badge,
but with the same "Couldn't load this conversation's earlier messages" text and the same
"Untitled" display.

• Removing the bridge-session and atis-latch records from the affected transcripts does

not fix those sessions. Worth recording as a negative result: the stuck state is not
(or not only) in the transcript. Sessions that load correctly also contain atis-latch
records, and the extension re-appends atis-latch + mode on open — two previously
working transcripts each grew ~166 bytes simply from being browsed.

• claude --resume <session-id> from the CLI loads full history correctly in every case,

including sessions the extension cannot render. That is the reliable workaround.

Minor note for anyone debugging transcripts: titles are stored as aiTitle on
ai-title records and customTitle on custom-title records — there is no title key.
Scanning for the wrong key makes fully-titled sessions appear untitled.

Personal note: this is why I don't trust new features added to the developer tools. Your UX is a hot mess. With so many features that don't work across different tools or that break other existing features within a tool, the bugs pile up and become a pattern of negligence, leading to erosion of customer confidence. You sold me an easy feature to enable that instantly damaged my progress and derailed me for hours. Marketing a feature in the tool that breaks what the user is working on without warning or any way to revert is the worst move you could possibly make here.