[Bug] Desktop 0.5.2 re-runs onboarding on every launch on a second machine — new Welcome channel + duplicate Honey each time #3727

Activity

1. jbforge commented on Jul 30, 2026

   

   jbforge

   on Jul 30, 2026

   More actions

   There may already be a fix in flight for this: PR #3441 ("fix(desktop):
   preserve cross-install agent identities", open, last updated 2026-07-30)
   enforces "one persona_id, one keypair" at the central managed-agent
   key-generation boundary and explicitly lists onboarding among the covered
   creation surfaces, reusing retained kind:30177 persona links instead of
   minting duplicates. Worth checking whether that branch closes this before
   anyone starts a separate patch.

   Separately, here is a mechanism that would produce exactly the "every
   launch" cadence reported here, traced at origin/main (4d47aa83):

   The per-launch guard is a localStorage marker that is only written after
   the whole seeding sequence succeeds, inside a catch that swallows the
   failure.

   • The launch-time effect skips seeding only when
     hasEnsuredWelcomeChannel(pubkey, communityScope) is true
     (desktop/src/features/onboarding/hooks.ts:578-593).
   • That marker is written by markWelcomeChannelEnsured, which runs last
     in seedWelcomeExperience, after ensureWelcomeTeam and
     ensureWelcomeCanvas (hooks.ts:52-64). Any throw in either lands in the
     catch at hooks.ts:60-62, which does console.warn and returns — the
     marker is never set.
   • ensureWelcomeTeam is not atomic. provisionWelcomeTeam
     (desktop/src/features/onboarding/welcomeGuide.ts:268-341) mints each
     missing starter via createManagedAgent, and then does several more
     awaited steps — updateManagedAgent to set each teammate's allowlist, and
     ensureWelcomeTeamMembership. A throw at any of those points leaves the
     newly minted keypairs on disk and the marker unset.

   Result on the next launch: seeding re-runs, and whether it re-mints depends
   entirely on the reuse guard.

   The reuse guard is pickWelcomeTeamStarterAgentForRelay
   (welcomeGuide.ts:108-121). It only matches an existing record when all
   three hold:

   agent.teamId === WELCOME_TEAM_ID &&
   agent.personaId === starter.personaId &&
   isAgentScopedToRelay(agent, relayUrl)

   isAgentScopedToRelay (welcomeGuide.ts:56-62) returns true for a null
   target relay, but otherwise requires
   normalizeRelayUrl(agent.relayUrl) === normalizeRelayUrl(relayUrl). The
   minting side writes relayUrl: relayUrl ?? undefined
   (welcomeGuide.ts:225). So if communityScope is absent or spelled
   differently on the launch that mints versus the launch that checks, the
   guard misses and mints again — permanently, once per launch.

   This is consistent with the reported duplicates being inert: provisioning
   never reached completion, which is the same reason the marker never latched.

   Two data points from machine B would discriminate between these, both
   from ~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json:

   1. For each of the four Honey records: the relay_url and team_id fields.
      Blank/differing relay_url, or a team_id that is not
      builtin-team:welcome, points at the reuse guard.
   2. Whether localStorage holds a
      buzz-welcome-channel-ensured:<scope>:<pubkey> entry for that community.
      Absent means the seeding sequence is throwing, and the console warning
      "Failed to seed the private Welcome experience." should name the step.

   Either way, the marker-after-the-fact ordering looks worth hardening on its
   own: a partially-completed seed that mints identities but never latches its
   guard will repeat forever, which is the shape this report describes.

   The existing failure-path notes in docs/welcome-kickoff-silent-failures.md
   (§3, "Any step throws") already call out ensureWelcomeTeam failure as a
   silent path — this looks like the durable-state consequence of the same
   swallow.
2. mansournorouzi commented on Jul 31, 2026

   

   mansournorouzi

   on Jul 31, 2026

   More actions

   Confirming this still reproduces on Desktop 0.5.3 (macOS 26.0, Apple M4 Pro), same shape as described: Mac Studio hosts the community, this MacBook signs in with the same identity as a plain member, and the starter trio (Fizz/Honey/Bumble) is re-minted with fresh keypairs on every launch.

   Two additional data points that may help narrow it down.

   1. A full uninstall — including the keychain — does not clear it

   I removed the app, ~/Library/Application Support/xyz.block.buzz.app, ~/Library/Application Support/Buzz, ~/Library/WebKit/xyz.block.buzz.app, ~/Library/Caches/xyz.block.buzz.app, ~/.buzz, the CLI symlink, and the buzz-desktop / secrets keychain item, then reinstalled 0.5.3 clean. The trio came back on join.

   Worth noting for anyone trying to repro with a new identity: the buzz-desktop keychain item is iCloud-synced, so deleting it locally doesn't give you a fresh identity — mine re-synced down byte-for-byte identical (41b963e7cbf8…) after reinstall. A clean-identity repro needs iCloud Keychain accounted for.

   2. Editing the state files doesn't survive a relaunch

   This rules out a config-level workaround:

   Attempt	Result
   managed-agents.json and teams.json set to [], agent-pids/logs/retention cleared	Trio re-provisioned ~45s after relaunch, fresh keypairs
   is_active: false + start_on_app_launch: false on the three built-in personas	App rewrote both flags back to true on launch and provisioned another set

   Four distinct keypair sets were minted in a single day from one install:

   Jul 30 16:00 UTC  33803d92…  bdc958f2…  3991fe17…   (original, pre-wipe)
   Jul 31 21:54 UTC  dad3d186…  67c60030…  59fe6a2e…   (after clean reinstall + join)
   Jul 31 22:01 UTC  9846a5bd…  …                       (after clearing state files)
   Jul 31 22:02 UTC  0faafb85…  abc03319…  1f646b92…   (after deactivating built-ins)
   

   Each set connects and starts publishing — e.g. setup-mode: nudge published channel_id=bd885300-… — so they're live in the channel, not just local records.

   Note on the built-in team

   buzz-desktop carries builtin:fizz / builtin:honey / builtin:bumble and builtin-team:welcome compiled in, along with the string Built-in teams cannot be deleted. Since the built-in team can't be removed and the personas' is_active flag is reset on launch, there appears to be no user-reachable way to opt a member's install out of provisioning — which is what makes this hard to work around while it's open.

   Happy to pull further logs or state dumps if useful.
3. driveforlight commented on Aug 2, 2026

   

   driveforlight

   on Aug 2, 2026

   More actions

   Another confirmation, with relay-side evidence of how the duplicates accumulate across sign-ins on one community.

   Setup: hosted community (*.communities.buzz.xyz). Machine A (Mac mini) is the original install and hosts a working managed agent. Machine B (MacBook Air) was previously signed into a different identity; on Aug 1 we did the full desktop sign-out ("wipe all my data") on the Air, then signed back in with the same identity as the Mini, joining the existing community. A mobile sign-in with the same identity happened earlier the same evening.

   Observed: immediately after the Air's re-sign-in, a fresh starter trio (Fizz/Honey/Bumble) was minted with new keypairs. The relay now holds, under the same owner identity (queried via CLI buzz users get), three sets of starter agents — identical display name and avatar per name, distinct pubkeys — the same signature as the OP's 4 Honeys:

   Name	Pubkeys (distinct, same profile)
   Honey	a94ea25121fbc3c40906d41d45a6ec32d5333613a554c4118520da0172228435 · 89f823e531868fac34ab849d6ff77e6b605669bb0da881744d3d398288ff36ce · b1af259e9108cc6baeaa24161ae02407f454f1b257025982c17923855f53275c
   Bumble	457d905ab054a5a7dd906f96a913775aad6d78acbcf93c9f5b12de305a56fc29 · 57fe34a6efbe62c16e3d19851b2a97d26660e174a68207920a05896b023e98e2 · 690f4f2760a903c551491db40d61b3d3cdbfcf360982397520ca71d43819cb01
   Fizz	5c7b0686b93cecfb8adf073b9c29dbd8a4eb65c521be598b209f2b043d7d138a (pre-wipe, its local key destroyed with the Air's wipe) · 95f7b97d47ae78ffe75520e95e2bbed31d4591d2eef66c8bd13f8000a6038702 (minted at the Air's re-sign-in)

   One trio is the original install's; one was minted at the Air's re-sign-in; the third most likely came from the same-evening mobile sign-in (unverified — happy to dig if useful).

   Variant detail vs the OP: in our case no duplicate Welcome channel appeared — but the existing Welcome channel's record now reports a created_at equal to the re-sign-in minute (metadata apparently republished by the onboarding run), and the freshly minted trio auto-joined that existing channel as bot members, inflating membership (the #2648 symptom).

   Interactions with other open issues, observed in the same session:

   • The owner could not delete the duplicate agents from the Air's UI — repeated errors (matches Cannot archive/remove stale duplicate agents from Buzzboard #2973).
   • @mentioning one of the seeded agents added it as a bot member of a channel it wasn't in and immediately prompted it (Mentioning a removed member silently re-adds them to the channel #3577) — so the duplicates aren't inert once mentioned.
   • A channel owner can clean up membership via CLI buzz channels remove-member for channels they own — that part works and is our current workaround; the agent identities themselves remain undeletable.

   Happy to pull more relay data (event ids, timestamps) if it helps land #3441.

   (Posted by an agent on behalf of the account owner, who hit this on her machines.)
4. lalagogo2012 commented on Aug 15, 2026

   

   lalagogo2012

   on Aug 15, 2026

   More actions

   Still reproduces on 0.5.11 (macOS 26.4), with the same Machine A / Machine B roles described above.

   Setup

   • Machine A (Mac mini) — hosted community on <redacted>.communities.buzz.xyz, runs the real agent team (4 agents, buzz-acp harnesses confirmed alive via pgrep/ps).
   • Machine B (MacBook Pro) — Buzz Desktop signed into the same identity, same community.

   What happened

   Machine B minted new agent identities repeatedly over ~1 hour. Three successive keypairs appeared under the single display name Fizz-idea:

   9c858da2…   07:42 UTC
   a4af0660…   07:50 UTC
   ccb00d9a…   08:40 UTC   ← after a clean uninstall + reinstall
   

   A full uninstall/reinstall of Machine B did not stop it — the fresh install immediately minted a whole starter team again. The Welcome channel went from 5 members to 10, the 5 additions all being Machine B mints:

   a4af0660  Fizz-idea
   e6fe81dc  Fizz
   f5a764cf  Honey
   4501de91  Bumble
   ccb00d9a  Fizz-idea
   

   All five report no presence and never ran — each posts only the needs configuration / set the provider field nudge.

   Operational impact (beyond clutter)

   The owner cannot reach the real agents from Machine B. Typing @Fizz-idea there autocompletes to Machine B's own dead Fizz-idea copy, so the mention is delivered to the unconfigured local agent and the working Machine A agent is never notified. From the owner's point of view the remote agents are simply unreachable — which is what #4814 describes, arrived at from a different direction.

   Deleting the mints from Machine B does not help: they are re-created, and their channel memberships persist on the relay regardless (cf. #5786). Removing them also requires the owner — an agent with bot role gets relay error 400: invalid: actor not authorized from buzz channels remove-member.

   Current workaround

   Uninstall Buzz Desktop from Machine B entirely and drive Machine A over remote desktop. Any second Desktop install signed into the same identity appears to re-mint on its own schedule.