Remote Control denial after `--resume` silently disables cross-machine discovery and messaging

Claude Code version: 2.1.237
Platform: macOS
Reproduced: 3/3 on 2026-08-20

Summary

If a second Claude Code process resumes a conversation whose Remote Control bridge is still held by another live local process, the resumed process is denied a bridge. It continues to work normally otherwise, but it cannot discover or message sessions on other machines for the rest of its lifetime unless the user runs /remote-control.

The notice explains that another process has Remote Control, but not the user-visible consequence: cross-machine session discovery and messaging are unavailable in this terminal. The internal log confirms the live-owner case:

[bridge:repl] Skipping: bridge session <session-uuid> from the resumed transcript is still served by local pid <pid>

Minimal reproduction

1. Start session A in a terminal and submit one user turn. (A transcript is not created until the first user turn is submitted.)
2. Confirm A holds a Remote Control bridge by finding a "type":"bridge-session" record in its transcript.
3. While A remains live, start session B with claude --resume <session-uuid>.
4. B displays this notice:

``text
Remote Control not started here · another Claude Code on this machine (started 9s ago)
already has Remote Control for this conversation · run /remote-control to move it to
this terminal
``

1. In B, agent discovery shows only local sessions. There is no indication that the cross-machine section is empty because B does not hold a bridge, rather than because no remote peers exist.

Actual result

The resumed session is denied its Remote Control bridge because session A still owns it. The session remains usable for ordinary work, but cross-machine discovery and messaging silently disappear. The only signal is the startup notice above, which does not say what functionality has been lost.

This is costly in practice: an agent in this state concludes that cross-machine messaging is broken and falls back to manual relay, which is what happened here before the cause was identified.

Related

Possibly the same underlying binding, different failure mode: #87213 reports the case where the
previous owner process is dead, and /remote-control cannot recover because it only retries the
doomed reconnect. This report is the live-owner case: the previous owner is still running, the
denial is deliberate, and /remote-control does successfully take the bridge over. Shared premise in
both: Remote Control binds to the conversation, and resuming replays that binding. Filing separately
because the request here is about observability rather than reconnect behaviour — happy for it to be
merged if maintainers see one root cause.

Expected result / requested improvements

I am not asking for the resumed process to take the bridge automatically. The current single-owner behavior may be intentional. Please make its consequences observable:

1. Make the denial notice explicit: this session cannot reach sessions on other machines until /remote-control is run.
2. Have ListAgents / /list-agents explain why the cross-machine section is empty when the current session has no bridge, instead of showing a bare local-only list indistinguishable from having no remote peers.
3. Provide a supported way for a session to query its own bridge state.

One caveat for (3): bridgeSessionId in ~/.claude/sessions/<pid>.json is absent on sessions that genuinely hold a bridge, so it cannot serve as a bridge-state check and produces false negatives.