[BUG] VS Code extension sessions with Remote Control active never get a bridgeSessionId: invisible in every peer roster, and outbound messages carry from="unknown" so replies are impossible

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.226)

What's Wrong?

A Claude Code session running in the VS Code extension panel (entrypoint: claude-vscode) shows "Remote Control is active" after /remote-control, but never gets a bridgeSessionId written to $CLAUDE_CONFIG_DIR/sessions/<pid>.json. A terminal session (entrypoint: cli) on the same machine, same version, same account, gets one immediately.

The consequences are all downstream of that missing id:

• The extension session never appears in any peer's ListAgents, so no one can address it by name.
• Its outbound messages arrive with from="unknown", so the receiver cannot reply. SendMessage itself reports the contradiction on send — "one-way: Remote Control is not connected, so the receiver cannot address a reply to this session" — while that same session's UI says Remote Control is active.
• from-name is populated with the session's auto-generated conversation title rather than its registry name, so the receiver can't map it back to a real session either, and the chat title leaks to the peer.

Sending works. Only identity and addressability are missing — the session behaves as bridgeOutboundOnly (a state the session-record schema models explicitly) while presenting itself as fully bridged.

Verified side by side, all three with the active banner showing:

| session | entrypoint | bridgeSessionId | in peers' ListAgents | repliable |
| --- | --- | --- | --- | --- |
| VS Code panel (macOS host) | claude-vscode | absent | no | no |
| VS Code panel (Linux container) | claude-vscode | absent | no | no |
| terminal (Linux container) | cli | session_01Mzb… | yes | yes |

Two cli sessions in different containers message each other cold, in both directions, first try, with a resolvable from=bridge:session_01…. Replace either end with an extension session and the reply path dies.

Relevant internals, in case it helps locate it: the session record has a dedicated writer for this field —

async function yfu(e, t) { await mFt({ bridgeSessionId: e }, t) }

— and the record schema declares bridgeSessionId (validated against ^(cse_|session_)[A-Za-z0-9_-]{1,128}$) alongside bridgeOutboundOnly. From outside the extension I can't tell whether it mints an id and fails to persist it, or never mints one.

What Should Happen?

An extension session with Remote Control active should mint and persist bridgeSessionId exactly as the CLI does, appear in peers' rosters, and send a resolvable from= address.

If outbound-only bridging is deliberate for this surface, the UI shouldn't report "Remote Control is active" without qualification, and SendMessage should say so before the send rather than in the result.

Separately: from-name should carry the session name, not the conversation title.

Error Messages/Logs

Send result from the extension session:

"success": true,
"message": "“…” → bridge:session_01Mzb… (one-way: Remote Control is not connected,
 so the receiver cannot address a reply to this session)"

Receiving CLI session, attempting to reply:

Message received: from="unknown", from-name="Update staging app image patch", from-mode="prompting"
No agent named 'Update staging app image patch' is reachable.
No agent named 'unknown' is reachable.

Steps to Reproduce

1. In a terminal, start claude and run /remote-control. Confirm bridgeSessionId appears in $CLAUDE_CONFIG_DIR/sessions/<pid>.json.
2. In VS Code, open the Claude Code panel as a separate session and run /remote-control. The banner reads "Remote Control is active". Inspect that session's sessions/<pid>.json — no bridgeSessionId.
3. From the extension session, SendMessage to bridge:<the CLI session's id>. It succeeds and is delivered, but the result reports one-way with Remote Control not connected.
4. In the CLI session, the message shows from="unknown". Any reply — to the from value or to the from-name — fails with "No agent named … is reachable".
5. Run /list-agents in the CLI session: other CLI and web sessions appear; the extension session never does.

Claude Model

Opus 5 (not model-dependent)

Is this a regression?

Not known to have worked previously.

Environment

• Claude Code 2.1.226; VS Code extension anthropic.claude-code-2.1.226-darwin-arm64
• macOS 15 (Darwin 23.6.0, arm64); CLI sessions inside Debian dev containers on Docker Desktop
• Single claude.ai Max account, one organization, OAuth
• Remote Control connected on all sessions; no isolatePeerMachines; crossSessionInbound: accept; none of CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC / DISABLE_TELEMETRY / DO_NOT_TRACK / DISABLE_GROWTHBOOK set

Context

This appears to be why the working method in #84920 (cold cross-machine sends via bridge:<sessionId>) can't be used from the GUI: the address it says to read is never written for claude-vscode sessions. Possibly the same family as #78563 and #78564, where desktop sessions show as bridged but never mint a working bridge handle.