Remote Control: a bridged session gives no indication of which machine is executing it — side effects land on an invisible host

Preflight Checklist

• [x] I have searched existing issues. The Remote Control issues I found are about connectivity and delivery (#86717, #85435, #86084, #87963, #88233); the sync ones are feature requests for cross-machine continuity (#52052, #81835, #72130). None asks for the session to say which machine is executing it. I filed #88493 earlier today, misdiagnosed it as duplicate execution, and retracted it — that misdiagnosis is itself the evidence for this report.
• [x] This is a single bug report
• [x] I am using the latest version

What's Wrong?

When a session is hosted on machine A and driven remotely from machine B, machine B's UI is indistinguishable from a local session. There is no host attribution anywhere: not in the Code-tab session list, not in the session header, not on the composer. The conversation, the tool calls and the streamed output all render exactly as they would if the work were happening on the machine you are looking at.

The information is available — the transcript records it in its very first line:

{"type":"bridge-session","sessionId":"…","bridgeSessionId":"cse_…","lastSequenceNum":0}
{"type":"queue-operation","operation":"enqueue","timestamp":"…","content":"<the prompt typed on machine B>"}
{"type":"queue-operation","operation":"dequeue","timestamp":"…"}

It is simply never surfaced.

Why This Matters

Every side effect lands on the host, not on the machine you are typing on, and nothing tells you that:

• Local output goes to the host. A skill that plays audio played it on the host machine. From the remote device it looked like the command had silently produced nothing.
• File and shell effects land on the host. Paths that exist on both machines (a project checked out at the same absolute path on two machines, which is the normal case for anyone with a desktop and a laptop) make the illusion complete — the agent reports editing J:\… and that path exists on both, so nothing reads as wrong.
• It produces false bug reports. Seeing the same conversation live on two devices, with no indicator that one of them is a view rather than a second execution, reads exactly like duplicate execution. I filed that as #88493 before working out that one host was executing and the other was mirroring. Someone without transcript access would have no way to tell the difference at all.

The underlying feature works correctly. The gap is that its most important fact — this is running somewhere else — is invisible.

Expected

A bridged session is visibly attributed to the machine executing it:

• the host machine's name on the session, in the session list and in the open session's header;
• some persistent marker (icon or badge) distinguishing "hosted here" from "hosted on <machine>";
• ideally a note at the point where output is produced that cannot cross the bridge — audio playback, opened windows, anything that renders on the host's own desktop.

Actual

No indication anywhere. The only way to determine which machine is executing is to read the raw transcript on disk, or to ask the agent to run hostname.

Environment

• Claude Desktop 1.32885.1.0, Windows 11 Home 10.0.26200.9168, MSIX (Claude_pzs8sxrjxfjjc)
• Bundled Claude Code 2.1.234, CLAUDE_CODE_ENTRYPOINT=claude-desktop
• claude.ai OAuth, personal account, Remote Control enabled
• Two Windows machines on the same account, same project path on both

Related

• #88493 — my own retracted report; the confusion this issue describes is what produced it.