[BUG] Opening a session created on another machine silently executes on that machine, with no host indication (escalation of #90433)

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?

Opening a session created on another machine silently executes on that machine, with no host indication (escalation of #90433)

What Should Happen?

Show the executing host name persistently in the session UI.
Warn when opening a session whose host differs from the current device.
Restore a way to scope the list to sessions local to this machine.

Error Messages/Logs

Steps to Reproduce

Setup: two Windows machines signed into the same Claude account, in different physical locations. In my case:

Machine A — ASUS ExpertBook B1502CBA laptop, hostname DESKTOP-JNMKF1S, at the office.
Machine B — desktop PC at home, different hardware entirely (AMD Radeon AI PRO R9700, 4 SSDs, Wi-Fi).

Both have the same user profile path, C:\Users\<user>\Downloads, which turns out to matter.

On machine A, open Claude Desktop, go to the </> code window, and start a new project/session with working directory C:\Users\<user>\Downloads, model Opus 5. Do some work so the session has history.
Leave machine A powered on and signed in. It does not need to be in use — in my case it stayed awake for four days with the lid closed and its display output not visible to me.
Physically go to machine B, in the other location. Open Claude Desktop there, same account.
In the session list, the session created on machine A appears (this part is already reported in #90433). Click it and continue the conversation.
Observe: the conversation resumes seamlessly, with full history. Nothing in the UI says the session is remote, and nothing names the executing host. It is indistinguishable from a local session.
Ask the assistant to identify the machine, or run this yourself in the session:
"$env:COMPUTERNAME"; (Get-CimInstance Win32_VideoController).Name; (Get-CimInstance Win32_DiskDrive | Measure-Object).Count

Expected: machine B's hostname, GPU and disk count.
Actual: machine A's. Every tool call — file reads, writes, downloads, installs — is executing on machine A, hundreds of kilometres away.

(Optional, triggers the separate defect in issue #<B>) Ask for anything requiring elevation, e.g. installing a driver. A consent.exe UAC prompt is created on machine A's desktop, which you cannot see from machine B. It hangs forever.

Frequency: 100% reproducible.

Why this is hard to notice

Three things conspired to make the misdirection invisible for over an hour:

The working directory is identical on both machines. C:\Users\<user>\Downloads exists on A and B, so every path in the transcript looked plausible. Had the session used a drive letter that exists on only one machine, I would have caught it in seconds.
ListAgents labels peer sessions "Remote Control", but says nothing about the session you are in. The current session is described as downloads-44 [4161f1] with no host attached.
Files written land on machine A. When the assistant offered to save a report to a file, it would have gone to a disk I had no access to. That failure mode is silent.
Additional note

This behaviour is new. In earlier versions the </> code window was independent per machine: sessions created on one computer did not appear on another, so continuing a session from a different machine was simply not possible. Whatever change introduced account-wide session listing (see #90874 on unconditional Remote Control bridge registration) also made it possible to attach to them, without adding any host indication to match.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.40609.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment
Claude desktop 1.40609.0.0 (Claude_1.40609.0.0_x64__pzs8sxrjxfjjc) · CLI 2.1.247 · Windows 10 Pro 22H2 build 19045.6466 x64 · session downloads-44 [4161f1]