Desktop batch deploy/restore mints duplicate keyed agent identities in the same local store

[flpthpaige]

Summary

Buzz Desktop 0.5.17 created five new managed-agent identities in one batch for five definitions that already had keyed instances in the same local managed-agents.json. The new identities have the same display names, persona IDs, team IDs, prompts/models, and owner as the existing agents, but fresh pubkeys.

The duplicate cards are hidden in Desktop's Agents screen because same-name records collapse to one visible card. The generated nest AGENTS.md renders all keyed records, exposing 13 rows for 8 names.

Observed evidence

Environment:

• Buzz Desktop 0.5.17
• macOS
• One local app-data store
• Hosted single community

Store state:

• 13 keyed ManagedAgentRecord entries
• 8 unique display names
• Five names have two distinct pubkeys
• The older identity for each name is a current channel member
• The newer identity for each name has no channel membership and has authored no messages

All five duplicates were minted within four seconds on 2026-08-18:

Name	Original created	Duplicate created	Definition/team relationship
Karoo (Research)	Aug 17	10:55:41Z	same persona ID and custom team ID
Ace (Content)	Aug 17	10:55:42Z	same persona ID and custom team ID
Luffy (COO)	Aug 17	10:55:42Z	same builtin persona and welcome team
Zoro (Store/Ads)	Aug 17	10:55:43Z	same builtin persona and welcome team
Sanji (FA)	Aug 17	10:55:45Z	same persona ID; no team ID on either record

Each duplicate was immediately started. Per-agent logs begin at its creation timestamp and show successful harness initialization and relay connection. They later exited cleanly. This rules out a passive display-only duplication.

At observation time:

• Desktop Agents screen displayed 8 cards.
• managed-agents.json contained 13 distinct keyed records.
• nest AGENTS.md displayed 13 rows.
• buzz channels members across all current channels found only the 8 originals.
• buzz messages search --author <duplicate-pubkey> returned no messages for all five duplicates.
• No duplicate had a running PID.

Expected behavior

Starting agents, deploying a team, restoring on launch, applying a snapshot, or reconciling definitions must reuse an existing keyed instance for the same owner + definition/team relationship. Identity creation must be an explicit owner action and must not silently mint a second keypair for an already-instantiated definition.

The Agents screen should also not hide multiple keyed records behind one same-name card; owners need pubkey-level visibility and a safe archive/remove path.

Actual behavior

A single local store accumulated five new keyed instances in one batch. The duplicates started successfully but never joined channels or sent messages. Desktop showed only one card per name, making the extra identities unmanageable through the UI.

Safety impact

• Silent creation of signing identities
• Unnecessary compute from automatic startup
• Ambiguous @mention resolution if duplicates later join a channel
• Hidden local identities that cannot be removed through Desktop
• Managed nest context reports an inflated roster

Suggested investigation

The shared timestamp and immediate startup suggest a batch deploy/restore/reconcile path rather than five independent user creates. Audit all paths that materialize ManagedAgentRecord instances from persona/team definitions:

1. Before key generation, resolve an existing keyed record by stable definition identity (persona_id/slug plus owner/community), not display name alone.
2. Make create-and-save atomic under a single lock to prevent concurrent batch tasks from each observing “missing” and minting.
3. Add a store invariant/test: at most one locally owned keyed instance per stable definition unless the user explicitly requests another instance.
4. Render duplicate keyed records distinctly in the Agents UI with pubkey prefixes and a recoverable removal/archive flow.
5. Log the creation reason/path for every minted identity.

Related issues

• Cannot archive/remove stale duplicate agents from Buzzboard #2973 — stale duplicate agents cannot be removed from Desktop
• [Bug] Second Desktop install creates duplicate agent identities, inflating channel membership #2648 — second Desktop install creates duplicate identities
• Desktop silently mints new agent keypairs for team/persona references to deleted managed agents #5868 — dangling team/persona references silently mint replacements
• Deleting a relay-synced agent definition deletes it account-wide and orphans live agents #3440 — deleting relay-synced definitions can orphan live agents

This report differs in that the originals and duplicates coexist in the same local app-data store, share the same definition/team relationships, and the duplicates were created and auto-started as one batch.