### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Summary Since Claude Code 2.1.292, a session that continues under /remote-control stops appending to the local transcript (.jsonl). The bridged process ke

[BUG] Regression (2.1.289 → 2.1.292): remote-control bridged session no longer writes local transcript, so local --resume restores a stale conversation

Status Open

Reported on v2.1.292

Maintainer reply None cached

Activity 0 comments · opened Oct 7, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Summary
Since Claude Code 2.1.292, a session that continues under /remote-control stops appending to the local transcript (.jsonl). The bridged process keeps working (it still writes file-history), but none of the conversation is persisted locally. After a disconnect, the only documented way to continue a remote-control session is claude --resume <local-session-id> followed by /remote-control again. That now resumes the conversation as it was before the bridge took over, and silently loses ~12 hours of conversation. The same workflow worked correctly on 2.1.289.

Environment

Windows 11 Pro 10.0.26200, native claude.exe (~/.local/bin/claude.exe)
Claude Code 2.1.292 (previous working version: 2.1.289)
Workflow: long-running interactive session in a local repo, continued from phone/web via /remote-control; after a disconnect, re-attached with local --resume + /remote-control.

Actual Results
The resumed conversation ends at 2026-10-06 ~23:25 +0200. Everything after that is missing locally. claude -r "<keyword from the lost part>" returns "No sessions match". Opening the respawned bridge session URL on claude.ai/code returns "This session cannot be found".

Impact

Silent loss of a long working session's history. Only work that the agent had written to files or git survived.
Because remote-control has no other way to reconnect after a disconnect, there is now no supported way to continue such a session.
The resume command the session itself reports points to a stale conversation, and resuming it spawns a second process on the same session id. The agent in the stale copy then acts on outdated context (in my case it re-armed background watchers for work that had moved on).
Loss of 10% 5-hour quota because the resume command woke up an old long conversation instead of the correct one.

Request

Persist bridged (sdk-cli) conversation turns to the local transcript again, or have --resume fetch the server-side history.
When a local session id has a newer bridged continuation, warn on --resume instead of silently loading the stale branch.
Make the "session cannot be found" case for a respawned bridge session recoverable, or document how to reach it.

What Should Happen?

Resuming on the latest state of the conversation (as on 2.1.289).

Error Messages/Logs

No error message at all. Claude Code just behave as if everything were

Steps to Reproduce

Start an interactive session locally (session id 9a50daf4-fbbb-50e4-ad02-60856d30ba4d).
Run /remote-control at 2026-10-06 23:19:07 +0200 (recorded in ~/.claude/history.jsonl).
Keep working through the bridge for ~12 hours (the conversation is active; the agent edits files).
The bridge disconnects. Ask the session for its resume command; it returns claude --resume 9a50daf4-....
Restart and run claude --resume 9a50daf4-fbbb-50e4-ad02-60856d30ba4d.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.289

Claude Code Version

2.1.292

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Debug evidence (all local, ~/.claude)

Transcript gap: projects/<repo>/9a50daf4-....jsonl jumps from timestamp 2026-10-06T21:25:32Z directly to 2026-10-07T09:36:42Z (the manual resume). No entries in between.
The session was still active in the gap: file-history/9a50daf4-.../ contains snapshots written 2026-10-07 11:12, 11:17, 11:21, 11:24 +0200.
Version / entrypoint comparison of local transcripts:

Older remote-control sessions on 2.1.289 (e.g. f16ba03a-..., 1a7a3766-...): every entry is "entrypoint":"sdk-cli", "version":"2.1.289" (1321 and 791 entries). So bridged sdk-cli processes did write the local transcript.
This session on 2.1.292: all 234 entries are "entrypoint":"cli", "version":"2.1.292". There is not a single sdk-cli entry, although the session ran bridged for ~12h.

Duplicate processes on one local session id after restart. In ~/.claude/sessions/:

50396.json: sessionId 9a50daf4-..., entrypoint sdk-cli, bridgeSessionId session_01WLWvxNNY4FJXhvgHLNFXN9, spawned 2026-10-07 11:35:41 by claude remote-control (pid 37176).
52056.json: sessionId 9a50daf4-..., entrypoint cli (my manual --resume), bridgeSessionId session_01RhLhq6pKYxEVHLDdkjCvbh.
48360.json: sessionId d7bd2424-64ee-562e-8b96-55e91bca42bd, sdk-cli, bridgeSessionId session_01BdB5TvLeqc6oW36kgGwoFJ; its .jsonl is 0 bytes.

So two live processes are attached to the same local session id and transcript file.

bridge-spawn/ contains cse_01WLWvxNNY4FJXhvgHLNFXN9-VYvrha and cse_01BdB5TvLeqc6oW36kgGwoFJ-7Y5GeS (append-system-prompt.txt, mcp.json), both created 11:35. Child command lines: claude.exe --print --sdk-url https://api.anthropic.com/v1/code/sessions/cse_... --session-id cse_... --input-format stream-json ....
A full-text search of every .jsonl under ~/.claude (and the Claude desktop AppData directories) finds no trace of the last ~12h of the conversation, including background task ids that the lost session printed in its final message.