Remote Control spawns session host processes without --resume, silently wiping conversation context (working local fix included)

Follow-up finding that makes a native fix more important: the wrapper-shim workaround described above turns out to be insufficient for daemon-initiated spawns.

The remote-control daemon spawns session hosts via its own executable path (child processes' argv[0] is the resolved binary, not the versions/<v> path string), so a wrapper placed at the versioned path never runs for those spawns. Since the binary is statically compiled, there is no LD_PRELOAD-style interception either. We confirmed this with --debug-file: the daemon logs [bridge:session] Spawning sessionId=... sdkUrl=... with no resume attempt, and the child comes up context-free.

We now run a second workaround layer: a watchdog loop (5 s) that detects any freshly spawned host lacking --resume whose session has a substantial local transcript, kills it immediately (even mid-generation - a half-written amnesiac reply is better than a delivered one), re-bridges via POST /v1/code/sessions/<id>/bridge, and respawns with --resume <uuid> --fork-session. Detection-to-replacement is ~15 s in practice.

This works, but it is a race against the user's first message. The daemon has all the information needed to do this natively at spawn time.

Reproduced on 2.1.226. Related: #70096 (same symptom), #85028 (env-reclaim variant). Some mechanism detail from a debug trace:

The restart adopts the same remote session ([bridge:init] Adopted session cse_01F1Y8… re-queued via bridge/reconnect, no new Created initial session), so the amnesia is purely local: the child spawned to serve it gets --print --sdk-url … --session-id <cse> with no --resume, and writes a fresh transcript UUID every time.

Three things not yet on any of these issues:

1. The wrapper-shim workaround fails because the spawner is built with pinToCurrentBinary: true and execs its own resolved binary path. PATH interception never fires.
2. A --resume= child path already exists in the self-hosted runner spawner. Transcripts already carry a bridgeSessionId: cse_… marker (#68606), so the bridge has everything it needs to pass --resume <uuid> --fork-session on adoption. The capability exists, it just isn't wired into the standalone bridge.
3. Every start burns a self-inflicted 400: bridge-pointer.json stores the id as session_…, reconnect tries that first and gets 400 Session not found, then succeeds with the cse_… form.

Also worth noting: --continue is no escape hatch for server operators. It forces single-session mode and skips environment reclaim, so there's currently no supported way to run a multi-session server whose sessions survive its own restart. The docs' Limitations section doesn't mention this failure mode, which presents as success: the app renders the full thread while the model answers from empty context.

Happy to provide full debug logs.

@mawikpartners-jpg taking you up on "happy to share details" - specifically the respawn half of the watchdog. After the kill and the POST /v1/code/sessions/<cse>/bridge, who spawns the replacement host, and with what credentials?

The sdk-url + per-session access token normally arrive in the daemon's work-poll ack, which an external watchdog doesn't hold. Is it:

• (a) the daemon re-spawns on its next poll (and if so, why with --resume this time?)
• (b) your watchdog spawns the child itself from the bridge POST response
• (c) something like claude --session-id <cse> --resume <uuid> --fork-session?

Also curious how you resolve cse -> local transcript uuid - marker in the jsonl, or your own index? Building the same thing into a supervisor and would rather match a known-working shape than rediscover the failure modes.