Mention picker fails to coalesce local persona definitions with their running channel-member instances

[daguiler76]

Summary

On Buzz Desktop 0.5.2, the @ picker can offer account-synced persona-definition rows as not in channel while omitting the actual locally managed, running instances of those personas that are bot members of the current channel.

This reproduces on a single Desktop installation. It does not require a remote agent, a second device, or a missing local key.

The local store already contains the join needed to resolve the correct identity:

instance.persona_id == persona.slug

The picker should coalesce the definition and instance, key membership and delivery by the instance pubkey, and use the persona only for presentation/configuration.

Reproduction

1. Use one Buzz Desktop 0.5.2 installation connected to a self-hosted community.
2. Have locally managed agents running on that same Desktop and subscribed to a channel. In the reproduced case the channel contained the owner plus Grok, Claude, and Codex as bot members.
3. Confirm through the relay/channel-members UI that those three agent pubkeys are current channel members.
4. In the channel composer, type @ or @codex.

Actual behavior

• The picker omits the running Grok, Claude, and Codex instances.
• It offers persona rows such as Bumble, Fizz, and Honey.
• Those rows are labelled managed by you · not in channel.
• Typing @codex manually leaves plain text only. The published kind:9 has the channel h tag but no Codex p tag, so the harness is not triggered.
• The same Codex identity remains reachable through Channel members → Codex → DM, and that DM works.
• Restarting Desktop does not change the result.

Expected behavior

• Current channel-member instances are offered and prioritized.
• Persona definitions linked to an existing instance are not shown as separate mintable/non-member candidates.
• Selecting Codex emits exactly one p tag for the existing Codex instance pubkey.
• No duplicate identity or harness is created or started.

Local-state control

The affected installation's managed-agents.json contains 16 records:

• 8 persona-definition records with populated display_name and slug, but pubkey: "";
• 8 running-instance records with populated pubkey and persona_id, but display_name: null and slug: null.

Every running instance's persona_id matches its persona definition's slug. All eight running instances are missing display_name.

For Codex specifically:

• the instance is active and configured to start with Desktop;
• there is no recorded startup error;
• its harness log shows a clean relay connection and subscription to the affected channel;
• the relay profile resolves correctly;
• the identity is not archived.

No full pubkeys, channel IDs, relay URLs, auth tags, or credentials are included here.

Interpretation

This appears to be a candidate-assembly/coalescing defect:

1. Persona-definition rows are admitted even though they have an empty pubkey.
2. Their running instances are not enriched with the linked persona label/configuration.
3. Membership is necessarily keyed by the instance pubkey, so the empty-pubkey definitions render as non-members while the valid member instances disappear.

The safe join is already explicit in local state:

instance.persona_id == persona.slug

The resulting candidate should retain the instance pubkey and runtime ownership; persona.display_name may provide the label. The join must not mint a new identity or infer that a remote instance is locally runnable.

Scope boundaries

• Related to Mention picker lists locally-managed agents instead of channel members, so an agent running on another machine can never be @-mentioned #3204, where the sanitized live reproduction was first posted: Mention picker lists locally-managed agents instead of channel members, so an agent running on another machine can never be @-mentioned #3204 (comment)
• Distinct from fix(desktop): decide mention eligibility for external agents from relay proofs #3676. That PR fixes the external-agent eligibility gate, while its author explicitly identified this single-install shape as a separate candidate-assembly defect at the persona/instance coalescing seam: fix(desktop): decide mention eligibility for external agents from relay proofs #3676 (comment)
• Distinct from Mention picker re-mints a persona on a second device: inbound kind:30177 persona_id link is discarded #3414. That issue covers a second device discarding an inbound kind:30177 persona association and re-minting the persona. Here both definition and runnable instance already exist locally on one installation; the picker still fails to join them.

Environment

• Buzz Desktop 0.5.2
• macOS
• One Desktop installation
• Self-hosted community
• Locally managed agents running through Buzz ACP harnesses

[iroiro147]

Submitted PR #4107 to fix this.

Root cause identified: The mention candidate assembly filtered persona candidates only by managedAgentPersonaIds (personas linked to managed agent definitions), but running instances with personaId set (channel members or relay agents) were not tracked. This caused orphaned persona definitions (no pubkey, no instance) to appear while running instances were omitted.

Fix: Added instancePersonaIds to track personas that have running instances (from channel members, relay agents, or managed agents with pubkeys). Persona candidates are now filtered to exclude any persona with a running instance.