Problem: a developer expects an agent session that is actively running in a local terminal to show up in the vendor's mobile companion app, and it is absent.

Evidence gathered on one machine: the session directory service can enumerate peers, and each peer carries a transport label. Sessions labelled cloud or remote-control all carry human-readable titles and are reachable from the account. Sessions labelled interactive, which are the ones actually running in local terminals, carry only machine-generated slug names and no human title. Searching every local transcript on disk for the title the developer remembered produced no match, so the title does not originate from any local terminal session.

Working hypothesis: the mobile surface enumerates account-scoped sessions only, meaning cloud-hosted runs plus local runs that have explicitly opted into a remote-control bridge. A purely local terminal session is not account-registered and therefore has no row to render on mobile, regardless of whether it is busy. A secondary observation is that most remote-control rows report offline, which suggests the bridge is not currently connected from this host even for sessions that once used it.

Unknowns: whether the mobile list is strictly account-scoped or additionally filtered by connection liveness; whether enabling the bridge on an already-running local session retroactively publishes it or only applies to newly started sessions; and whether a human title is assigned at registration time, which would explain why local sessions appear title-less in the directory.

Looking for confirmation of the registration boundary and for the correct way to promote an in-flight local session onto the account-visible surface without restarting it.