[BUG] Regression since ~2026-09-12: Remote Control sessions have 0 teleport-events, so opening them from another machine (VS Code Remote tab / --teleport) yields an empty session (worked 2026-08-26 → 09-11)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest: #93892 — a docs issue whose 2026-09-16 comment describes the same regression on 2.1.273; #79417 — same symptom for a web session in July, stale)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.278, VS Code extension bundle)

What's Wrong?

Between 2026-08-26 and 2026-09-11 a Remote Control session started on machine A could be opened on machine B (VS Code extension → session picker → Remote tab, or claude --teleport) with its full conversation. Since 2026-09-15 every Remote Control session returns 0 teleport events, so the teleport "succeeds" with 0 messages and the extension silently opens a blank new conversation. Nothing changed on my side; the server-side store is simply empty for new sessions.

The regression is not tied to the client version: sessions created on 2026-09-11 with cc 2.1.269 have hundreds of teleport events, sessions created on 2026-09-15 with cc 2.1.266 / 2.1.270 have zero.

Environment

• Both machines: Windows 11 Pro 10.0.26200, VS Code extension anthropic.claude-code-2.1.278-win32-x64 (bundled CLI 2.1.278), same Claude Max account
• Sessions are Remote Control sessions started from the VS Code extension (environment_kind: "bridge", config.origin: "claude_code_vscode", tag remote-control-sdk), repo YediSys/Pery.Hub, remoteControlAtStartup: true
• Example broken session: cse_01CxtreK6hxGuiasCHiYWBSp (created 2026-09-21T12:10:43Z on machine A)
• Example working sessions: cse_018yVuXCqfVuXseN2ji4pJv4 (2026-09-11, cc 2.1.269, 653 teleport events), cse_01JnNoyGiJocdJ1xKCw73S81 (2026-09-11, cc 2.1.269, 1000+ teleport events)
• Example broken sessions from the first bad day: cse_01GaSayzZyKbSneCxRi16WyW, cse_01P9bbcqgfwsrT5jpWfrZUrv (2026-09-15, cc 2.1.270, 0 teleport events)

Steps to reproduce

1. Machine A: open the repo in VS Code, start a session (Remote Control on at startup), have a conversation. The conversation is visible on claude.ai/code under the session URL.
2. Machine B: VS Code → Claude Code session picker → Remote tab → click that session.
3. Observe.

Actual

Extension log on machine B (2026-09-21 18:04 local):

Received message from webview: {"type":"request","requestId":"h234vlrzso","request":{"type":"teleport_session","sessionId":"session_01CxtreK6hxGuiasCHiYWBSp"}}
Teleport started for session session_01CxtreK6hxGuiasCHiYWBSp
CCR teleport-events returned no events for session_01CxtreK6hxGuiasCHiYWBSp, trying session-ingress
Fetched 0 log entries for session session_01CxtreK6hxGuiasCHiYWBSp
Saved teleported session 976aa699-d784-4bae-a91f-a4f1000eb1fe with 0 messages
Teleport succeeded for session session_01CxtreK6hxGuiasCHiYWBSp in 1126ms (0 messages)
launch_claude ... "resume":"976aa699-d784-4bae-a91f-a4f1000eb1fe","freshStartIfUnresumable":true
Nothing to resume for session 976aa699-d784-4bae-a91f-a4f1000eb1fe on channel 9tfmhgni7gs; starting a new conversation

Local stub written: {"type":"teleported-from","remoteSessionId":"session_01CxtreK6hxGuiasCHiYWBSp","messageCount":0}. Six teleport attempts on this machine (2026-09-15, 09-17, 09-21) all produced messageCount:0 stubs. No error is surfaced to the user — the tab just opens empty.

Expected

Either the behaviour from 2026-08-26 → 09-11 (Remote Control session opens on the other machine with its transcript), or — if transcript sync for Remote Control sessions is intentionally off — the Remote list should not offer those sessions / should say "transcript not available" instead of silently creating an empty session.

Measurements (server side, same OAuth token, GET /v1/code/sessions → 500 most recent sessions, all environment_kind=bridge; per day: 2 sampled sessions, count of GET /v1/code/sessions/{id}/teleport-events?limit=1000)

| created (UTC) | sessions | container_cc_version | teleport-events (2 samples) |
|---|---|---|---|
| 2026-08-16 … 08-25 | 192 | 2.1.233 → 2.1.245 | 0, 0 (every day) |
| 2026-08-26 | 21 | 2.1.245 | 51, 1000 |
| 2026-08-27 | 27 | 2.1.247 | 445, 827 |
| 2026-08-28 | 18 | 2.1.250 | 1000, 728 |
| 2026-08-31 | 7 | 2.1.250 | 1000, 1000 |
| 2026-09-02 | 4 | 2.1.258 | 1000, 642 |
| 2026-09-05 | 22 | 2.1.261 | 425, 1000 |
| 2026-09-08 | 26 | 2.1.263 | 1000, 1000 |
| 2026-09-11 | 2 | 2.1.269 | 1000, 653 |
| 2026-09-15 | 22 | 2.1.266 / 2.1.270 | 0, 0 |
| 2026-09-16 … 09-21 | 63 | 2.1.273 / 2.1.274 / 2.1.278 | 0, 0 (every day) |

(Some working-window days also have individual sessions with 0 — those are short sessions; from 09-15 on there is not a single non-zero session.)

For the broken example session the data clearly exists server side — it is just not in the teleport store:

• GET /v1/code/sessions/cse_01CxtreK6hxGuiasCHiYWBSp/teleport-events → 200, data: []
• GET /v1/session_ingress/session/cse_01CxtreK6hxGuiasCHiYWBSp → 404
• GET /v1/code/sessions/cse_01CxtreK6hxGuiasCHiYWBSp/events → 1543 events (user / assistant / system / result), which is what claude.ai/code renders

Client-side observations (2.1.278 bundle)

• The bridge REPL only installs the transcript writer / backfill ([bridge:repl] Session persistence enabled — transcript writer + hydrate readers registered) when enableSessionPersistence is true, and at the call site that is … || tengu_amber_relay (GrowthBook). The cached value in ~/.claude.json for this account is tengu_amber_relay: false (also tengu_teleport_send_to_cloud: false). No Session persistence enabled line appears in any retained extension log (earliest retained: 2026-09-17).
• Feature overrides are compiled out in the release build (getEnvironmentOverrides(){return null}, readConfigOverrides(){return}), so there is no local way to re-enable it.
• The VS Code extension's Remote list does not distinguish bridge sessions (0 teleport events) from cloud sessions (e.g. cse_01F1AoEuStrNpwNVMsRXNxPy, environment_kind: anthropic_cloud, 110 teleport events), and treats a 0-message teleport as success.

So this looks like a server-side flag / rollout change around 2026-09-12 → 09-15 rather than a client regression. Related: #93892 (worked on 2.1.268 on 2026-09-12; the 2026-09-16 comment there reports 0 events on 2.1.273), #79417.