Remote Control: no host provenance in the session UI — can't tell which machine runs a session (add hostname to session info + disconnect message)
Not a duplicate of #57361 / #58665 / #60790 — those report disconnect/resume failures themselves (all closed). This issue is about the missing information that makes that class of incident expensive: the UI never tells you which machine hosts a session's worker. Sibling of #64748 (per-message provenance); this is per-session host provenance.
Setup: 2 machines × 2 accounts, each running claude remote-control on pinned config dirs (CLAUDE_CONFIG_DIR), plus desktop-app local sessions; sessions viewed from the mobile app / desktop app.
Problem: RC auto-generated session names default to a hostname prefix (--remote-control-session-name-prefix), but once AI auto-titling renames the session, the host information disappears from the UI permanently. After that, nothing in the session view (header / info pane) identifies the hosting machine/environment.
Real incident (2026-07-02, CLI 2.1.197): a session showed "The bridged Claude Code process stopped responding mid-turn — check your terminal". Which terminal, on which machine? Identifying the host took ~30 minutes of cross-machine transcript/log/git-reflog forensics. Notably, the worker had actually survived and completed its turn (it kept pushing its results to the repo while the UI showed the error) — knowing the host before resending also matters to avoid double-executing a turn.
Requests:
- Show environment name + hostname persistently in the session header/info pane (not only in the create-session environment picker).
- Include the host machine name in the bridged-disconnect error message ("…stopped responding on iMac-3").
Environment: Claude Code CLI 2.1.197 (remote-control, launchd-resident), Claude desktop 1.17377.2, macOS 26.5; sessions viewed from iOS mobile app and desktop app.
Workaround we use: a SessionStart hook stamping hostname · config-dir · session-id into the first assistant reply, so the host survives in the scroll-back even after the bridge dies.
4 Comments
Wtf
Still the case on Claude desktop 1.34493.1: session info /
get_sessionmetadata carry no hostname, so with two machines signed into one account there is no way to tell from the UI which machine a session runs on. (Ran into this again today while triaging a misclick-archive — see #88636.)Corroborating this from a different angle: same root cause, but the practical problem for us isn't cross-machine forensics, it's telling projects apart in the session list on one machine.
We run
claude remote-controlacross 7 local git clones, each with its own--remote-control-session-name-prefixset explicitly (confirmed viaps auxagainst the live processes, and viagit configfor the per-clone prefix). So this isn't a missing-config case — the prefix is set correctly and running. Once a session has enough conversation content for the auto-titler to kick in, the prefix is dropped from the display name with no trace of it anywhere else in the session list, exactly as this issue describes. With several clones active, unrelated sessions about similarly-numbered issues in different repos become visually identical in the sidebar (e.g. "Issue #211 root cause" in two different projects).One data point that may help narrow down a fix: sessions dispatched as named background agents (an explicit name given at creation) never get auto-retitled at all — an explicit name appears to suppress the auto-titler outright — so those keep their prefix indefinitely. Ordinary interactive sessions have no equivalent way to opt out.
Claude Code CLI 2.1.246, reproduced via Remote Control (Pro/Max subscription, not API-key/Bedrock/Vertex).
__User Claude Code to help writing the description of our case.__
Two other issues resolution of which would help curing my pain here: #89623 or #90030
+1 with a concrete case, and one detail I don't think has been raised yet: auto-titling doesn't just strip host information, it can produce a title that names the wrong machine.
Setup: one account, ~126 sessions across three hosts — a NUC (
bb-tech-omarchy), a laptop, and several cloud sessions, all via Remote Control.A session running on the laptop was originally titled "Omarchy flash drive setup" (it was setting up the NUC remotely over SSH). The auto-titler later renamed it to "Omarchy Set Up on Nuc". The session has never run on the NUC. The title is named after the session's subject, not its host, and now reads as a positive assertion about which machine it's on — one that happens to be false.
That's a step worse than the missing-label problem in the original report. A blank field makes you go look; a confidently wrong one stops you looking. I acted on that title and had to be corrected.
Neither the mobile app nor the desktop app shows a hostname anywhere in the session list, so there was no way to check from the UI. Determining which sessions were local required, on the machine itself:
~/.claude/projects/*/*.jsonl— only sessions that actually ran on that host have files there. On the NUC that was 2 out of 126.ListAgents, which labels every peer only asRemote Controlorcloud— no hostname, no device, so it confirms "not local" but never tells you which remote host.Both asks in this issue would have prevented it. One addition:
Host provenance should be immutable metadata, not part of the title. The prefix conventions people are using here (and the
[nuc]/[lap]scheme I've now adopted) are all workarounds that live in a field the auto-titler owns and will eventually overwrite. A separate host/device field that titling cannot touch fixes this permanently; a naming convention only defers it.Also worth surfacing in
ListAgentsoutput — it's the one place an agent can enumerate peers, and it currently can't tell you which machine any of them is on either.CLI 2.1.251, Claude Desktop 1.40609.0, Remote Control, Linux.