fix(desktop): Bot Mode Cloud alias identity survives hosted handoff and Cloud-only rosters - #92860
Merged
Merged
Conversation
A Desktop per-profile alias (e.g. moxie with a Cloud override) routes to a
remote backend's root profile: route { connectionId, profile: 'moxie',
targetProfile: 'default' }. Once the hosted backend answers the roster
itself, the row's identity is (connection, 'default') — a different key
than the alias meta — so the friendly name regressed to the raw Cloud
hostname after activation, and Cloud-only rosters showed generic 'Hermes'
instead of the configured alias (#89131).
Add a connection-exact alias index built from the credential-free route
inventory, keyed by (connectionId, targetProfile). displayName,
botRosterMeta, and botFriendlyNames consult it so the claimed backend row
reads as the alias (and its title/meta), while:
- same-named defaults on OTHER connections never borrow the identity
- two aliases claiming one backend row fail closed
- the local default and un-aliased remote defaults keep existing behavior
Evidence: @TheAirick's controlled candidate testing on #89131.
Contributor
૮ >ﻌ< ა ci reviewran on 3378ab5 — fix(desktop): Bot Mode keeps Cloud alias identity after host
|
alt-glitch
added
type/bug
This was referenced Aug 23, 2026
This was referenced Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #89131 — Bot Mode now keeps a per-profile Cloud alias's friendly identity ("Moxie") after the alias hands off to the hosted backend, and renders the configured alias instead of generic "Hermes" when Cloud is the only active source.
Root cause
A Desktop per-profile alias routes to a remote backend's root profile: the route reads
{ connectionId: C, profile: 'moxie', targetProfile: 'default' }. Once the hosted backend answers the roster itself, the row's identity is(C, 'default')— a different key than the alias's meta (C::moxie/'moxie'). Nothing bridged the two:botRosterMetaintentionally never let remote rows borrow local meta ("twodefaults must not share a title"), so the backend row lost the alias title on the first roster refresh after activation — regressing to the raw Cloud hostname /@default-…identity.defaultrow hitdisplayName's untitled-default fallback and rendered as generic Hermes.Fix
Introduce a connection-exact alias index (
aliasRouteIndex) rebuilt from the credential-freehost.profileRoutes()inventory on every roster fetch, keyed by(connectionId, targetProfile)— never a bare name. Only genuine aliases (profile !== targetProfile) participate.displayName: a backend row claimed by an alias reads as the alias name (title, when set, still wins) — never "Hermes" or a hostname-derived label.botRosterMeta: the claimed row resolves the alias's meta (v2C::moxiekey, then legacy v1moxiekey) when it has none of its own — the one sanctioned, route-proven exception to "remote rows never borrow local meta".botFriendlyNames: the alias name/title rides the claimed row so@moxiekeeps resolving in mentions after handoff.Safety properties, aligned with the fail-closed design settled in #88680 / #90006:
defaultrows on other connections never borrow the identity (index is keyed by connection);host.profileRoutes(older desktops) → empty index → prior behavior; a failed route read keeps the last good index.Tests
New
tests/cloud-alias-identity.test.mjs(7 source-shape tests, vm-exec pattern) covering: identity persistence across the hosted handoff (v2 and legacy v1 meta keys), the Cloud-only "sole bot labeled Hermes" reproduction, no cross-connection leakage, ambiguous-alias fail-closed, the alias row not self-claiming, mention resolution after handoff, and index refresh dropping stale claims.node --test tests/*.test.mjs)node --check plugin.jscleanCredit
Huge thanks to @TheAirick for the controlled candidate testing on #89131 — the isolated live test that proved correct Cloud routing while pinpointing the residual identity regression, and the clean-install Cloud-only reproduction that narrowed the failure to identity propagation rather than the alias/default collision.
Infographic