[BUG] VS Code extension: forking a session while Remote Control is on produces a child with EMPTY history (registers as a fresh bridged session, not a fork)

Summary

Forking a session from the Claude Code VS Code extension while Remote Control is
enabled produces a new window that comes up with the banner
Remote Control is active · Continue here, on your phone, or at claude.ai/code
and zero inherited conversation history. The model in the new window has no
context at all.

The child is not recorded as a fork anywhere. It is registered as a *fresh
interactive session that got bridged*. There is no error, no warning, and no
indication that history was dropped — the window simply looks like a normal fork
until you ask the model something that depends on prior context.

This looks like the mirror image of #78563 ("forked sessions never enable Remote
Control"): same fork/bridge seam, opposite side. There, the fork path never
reaches the bridge-enable call. Here, the bridge path appears to win the race and
the session is created fresh, so the fork's history seeding never happens.

Environment

| | |
|---|---|
| Claude Code (VS Code extension) | 2.1.251 |
| claude --version on PATH | 2.1.181 |
| OS | Windows 11 Pro 10.0.26200 |
| Plan | Max |
| Remote Control | enabled (bridges automatically on session start) |
| entrypoint in session records | claude-vscode |

Steps to reproduce

1. Have a long-running session in the VS Code extension, with Remote Control

enabled by default so sessions bridge automatically a few seconds after start.

1. Fork the session into a new window.
2. The new window shows the Remote Control banner and an empty conversation.
3. Ask the model anything referring to earlier work — it has no context.

Expected

Per the docs, a Remote Control session "carries over your current conversation
history", and a fork inherits its parent's transcript. The child should have the
parent's history whether or not it is bridged.

Actual

The child session has none of the parent's history, and carries no record of
having a parent.

Evidence

1. The child transcript opens as a bridge session with sequence 0

First record of the child's ~/.claude/projects/<project>/<child-uuid>.jsonl:

{"type":"bridge-session",
 "bridgeSessionId":"cse_01RsY…",
 "lastSequenceNum":0,
 "sessionId":"319b94c3-…",
 "ownerAccountUuid":"…","ownerOrganizationUuid":"…"}

lastSequenceNum: 0 and no inherited conversation records. The first user
record in the file has parentUuid: null — no ancestor chain. Total file at the
moment of first prompt: 38 records / 40 KB, all of it the new conversation.

For contrast, a normally-started session in the same project begins with ordinary
conversation records carrying entrypoint: "claude-vscode", a slug, and a
parent chain.

2. The Desktop-side session record has a bridge id but no fork parent

~/.claude/sessions/<pid>.json for the child:

{"bridgeSessionId":"session_01RsY…",
 "kind":"interactive",
 "entrypoint":"claude-vscode",
 "sessionId":"319b94c3-…",
 "pid":34320, "pidDomain":"win32:<host>",
 "startedAt":1788117446827,
 "version":"2.1.251",
 "name":"<derived>","nameSource":"derived"}

Note kind: "interactive" and the absence of forkedFromSessionId (the key
#78563 identifies as the fork marker) or any parent pointer. The bridge id here
matches the cse_01RsY… in the transcript header, so the bridge registration
succeeded — it is only the fork lineage and history seeding that are missing.

3. Timing: the parent quiesced 2 seconds before the child started

Transcripts in the project directory, by mtime (local time):

cfde1c9b…jsonl   9,363,037 bytes   3942 recs   12:17:24   <- parent, last write
                                               12:17:26   <- child startedAt
1ef5d896…jsonl   9,363,037 bytes   3942 recs   12:18:42
319b94c3…jsonl      40,676 bytes     38 recs   12:19:56   <- child (this bug)

4. The same parent forked successfully when the result was NOT bridged

Three transcripts in this project are identical in size at 9,363,037 bytes /
3942 records (12:16:56, 12:17:24, 12:18:42). They are not byte-identical: each
is the same history with sessionId rewritten and every record's uuid
regenerated (consistently, so parentUuid chains stay intact), while
logicalParentUuid — which points outside the file — is preserved. Because a
UUID swap is length-preserving, a correct fork lands on exactly the same byte
count, which is a convenient fingerprint for spotting one.

Field-level diff of record 1 between two such siblings, after flattening:

DIFF .uuid       c3d663b3-…faae89  |  88991d4a-…f93777a
DIFF .sessionId  cfde1c9b-…f042475 |  1ef5d896-…6453a052

Two fields differ; everything else — content, timestamps, logicalParentUuid —
is identical. So history inheritance demonstrably works on this machine and in
this version, and the fork path clearly knows how to seed a child. The only
sibling that came up empty is the one that came up with Remote Control active.
That is what makes this look like a race or a mutually exclusive code path
rather than general fork breakage.

Notes

• There is no user-visible failure. The banner appears, the window looks healthy,

and the loss is silent until the model demonstrably lacks context. A warning
("this fork did not inherit history") would have saved the debugging time.

• Docs already describe several paths that deliberately drop earlier messages

(e.g. running /remote-control after Previous session is unavailable without
restarting first, and the v2.1.224–2.1.226 replacement-session behavior). If
the fork-while-bridged case is intentional, it is not documented, and it does
not announce itself.

• Possibly related: #78563, #34531, #42773, #60790.