Remote sessions don't clearly indicate which machine commands execute on (local vs. remote indistinguishable under one project)

Summary

When Claude Code is driving a remote machine, there is no persistent, obvious indicator of which machine the agent's commands (shell, file edits, process control) actually run on. When a local machine and a remote machine live under the same project group, their sessions are named and labeled identically, with no host distinction — so it is easy to lose track of whether you are operating on your local machine or a specific remote one.

What happened (real impact)

I have two machines — a local one and a remote one — set up under the same project. I ran a long debugging session believing it was targeting one machine, when it was actually executing on the other machine the entire time.

During the session the agent killed processes and launched an isolated, empty-profile test instance of an app on the wrong machine. That empty-profile state looked exactly as if the real app on that machine had been logged out / wiped. Only then did I realize every action had been happening on the wrong host. It was genuinely alarming — I briefly thought I had lost my login and data — and it wasted a lot of effort.

The hostname was present in low-level logs, but it was never surfaced in the UI, in the session name/label, or by the agent until very late.

Expected behavior

• A persistent, prominent indicator of the execution host in the header/status area.
• A clear visual distinction between local and remote sessions (e.g., color or badge), plus a heads-up when a session is remote.
• When local and remote sessions share one project group, session names/labels should include the host so they are distinguishable at a glance.

Severity

Usability + safety: the ambiguity can lead a user to run destructive commands on the wrong machine.

Environment

• Claude Code, remote-session feature, macOS.