[Bug] Deploy team to channel force-mints new agent keypair per persona (bypasses reuse)

[matthewdcage]

Summary

Deploy team to channel unconditionally mints a fresh Nostr keypair for every persona on every deploy, even when that persona already has a live managed instance on the same community. This inflates channel membership with same-display-name bots and breaks @mention targeting / agent coordination.

Root cause is explicit in AddTeamToChannelDialog.tsx: forceNewInstance: true is set for every persona input, which bypasses the existing reuse path in provisionChannelManagedAgent() (findReusablePersonaAgent).

Root cause (upstream main)

desktop/src/features/agents/ui/AddTeamToChannelDialog.tsx (~line 152):

personaId: persona.id,
teamId: team.id,
// One persona can be deployed under multiple teams with different instructions.
forceNewInstance: true,
role,

forceNewInstance: true skips reuse in desktop/src/features/agents/channelAgents.ts:

if (
  input.personaId &&
  !input.forceNewInstance &&
  context?.managedAgents &&
  context.channelMemberPubkeys
) {
  const reusable = findReusablePersonaAgent(/* … */);
  // attach existing instance instead of createManagedAgent()
}

Meanwhile create_managed_agent in Tauri always generates new keys — there is no server-side dedup by persona_id. Frontend reuse is the only guard, and team deploy disables it.

Why the original comment does not hold

The comment claims personas need distinct instances per team because of "different instructions." In current code, persona systemPrompt is persona-scoped (not team-scoped at mint time). teamId on the record is deployment provenance / runtime instruction layering — it does not require a new keypair. Re-attaching an existing instance to another channel achieves the same outcome without spawning parallel identities.

Reproduction (single machine, single community)

1. Create managed instances for personas (e.g. Welcome team: Fizz, Honey, Bumble) and deploy the team to channel A — note instance pubkeys.
2. Deploy the same team (or overlapping personas) to channel B via Deploy team to channel.
3. buzz channels members --channel <B> shows new bot pubkeys with the same display names as step 1.
4. Repeat across N channels → N duplicate pubkeys per persona name on the relay.

Also: batch deploy within one channel did not refresh reuse context after each attach in createChannelManagedAgents(), so later personas in the same batch could still mint duplicates.

Observed impact

Single ai-advantage community, single Desktop install:

• ~24 distinct bot pubkeys across channels vs 11 canonical running instances in managed-agents.json
• Duplicate groups: Fizz (×4), SEO Agent (×4), Google Ads (×2), Process Engineer (×2), Honey/Bumble short-name variants
• Manual channel cleanup restored 11 canonical pubkeys, 0 stale bots

Expected behavior

• Deploy team to channel should reuse existing managed instances (attach + membership).
• If persona already in channel, skip mint (idempotent deploy).
• Batch deploy refreshes reuse context after each attach.
• Optional hardening: backend refuse second instance per persona_id unless explicit force_new_instance; --pubkey on draft-update; Instance pubkey in AGENTS.md.

Proposed fix

Validated locally (uncommitted WIP):

1. Remove forceNewInstance: true from AddTeamToChannelDialog.tsx
2. Add findPersonaAgentInChannel() in provisionChannelManagedAgent()
3. Refresh context in createChannelManagedAgents() after each attach
4. Hardening: draft-update --pubkey, AGENTS.md Instance pubkey column, buzz-acp roster poll

Tests: buzz-cli 261 ✅, buzz-acp 633 ✅, desktop JS 3779 ✅, Tauri managed_agents 42 ✅

Related issues

• [Bug] Second Desktop install creates duplicate agent identities, inflating channel membership #2648 — duplicate identities on second Desktop install
• Cannot archive/remove stale duplicate agents from Buzzboard #2973 — cannot archive/remove stale duplicate agents
• [Bug] Renaming or re-adding personal agents can desynchronise identity and break @mentions #2423 — rename/re-add desynchronises identity
• [Bug] Agents from different communities collide in channels, causing duplicate @mention targets and missing avatars #2515 — cross-community collision

[matthewdcage]

Related open issues — duplicate-identity cluster

Cross-links for triage (all reproduce on upstream block/buzz main unless noted):

Issue	Link
#2648	Second install mints default roster
This issue	Team deploy forceNewInstance: true mints on single install
#2973	Stale pubkeys visible on Buzzboard, not Desktop; archive CLI auth
#2423 / #3350	Rename/mention drift; --pubkey draft-update mitigation
#3204 / #2508	Mention picker pre-gate (#2149) — separate fix, discussed there
#2910	Multi-user default Fizz collision — same disambiguation need

Upstream code: AddTeamToChannelDialog.tsx line ~152 (forceNewInstance: true); reuse guard in channelAgents.ts (!input.forceNewInstance).

Cleanup workaround (upstream CLI): buzz channels remove-member for stale bot memberships when archive is blocked.

PR to remove forceNewInstance + in-channel persona dedup in progress.

[dkapo88]

Independent confirmation on a different install, with the managed-agents.json numbers — and one detail that I think strengthens the case for simply deleting forceNewInstance.

Setup: macOS Buzz Desktop, single install, single community, 8 custom personas (not the Welcome trio). Deployed the same team to a channel twice, then deleted both channels.

Result: managed-agents.json went from 16 records to 32 — 8 persona definitions + 24 instances. The 16 extras arrived in two tight batches matching the two deploys:

2026-08-02T10:42:40  1
2026-08-02T10:42:41  5
2026-08-02T10:42:42  2   <- deploy #1, 8 instances
2026-08-02T10:43:20  2
2026-08-02T10:43:21  4
2026-08-02T10:43:22  2   <- deploy #2, 8 instances

Names duplicate exactly 2x each: Amp, Deepseek, Fable, Grok, Kimi, Luna, Opus, Sol.

The detail worth adding to the root-cause section: every one of the 16 clones carries the same persona_id as a live original. Overlap between the original persona_id set and the clone persona_id set is 8 of 8 — 100%.

clone persona_id counts (truncated ids)
607de77c-91b: 2   b4741488-c18: 2   847f065d-6ae: 2   builtin:bumb: 2
8c417c94-cf4: 2   01563b08-9d1: 2   builtin:hone: 2   builtin:fizz: 2

So findReusablePersonaAgent() would have matched on the first try for every persona in both deploys. Nothing about the deployment was ambiguous or novel — the reuse path was fully satisfiable and was skipped purely because the flag is hardcoded true at the call site. That is consistent with the argument in the issue that the "different instructions per team" comment does not justify a new keypair.

Second data point, on the teamId half. Of the 8 originals, 3 had team_id: "builtin-team:welcome" and 5 had team_id: null. The 5 null ones were provably not receiving the team's shared instructions — two of them (Fable, Amp) reported at runtime that their live system prompt contained no team instructions block at all, while the deployed clones (all 16 at builtin-team:welcome) did. Because the UI only surfaces the 8 personas and not the underlying instances, there was no in-app way to see that split or fix it.

I hand-set team_id: "builtin-team:welcome" on all 8 originals directly in managed-agents.json and pruned the 16 clones. After relaunch, Desktop accepted the hand-set team_id on records it did not provision, and the previously-null instances now load the team instructions correctly (verified by asking one to quote a specific numbered rule back). Final state: 16 records, 8 instances, 0 duplicates. That is a useful signal for the fix — attaching an existing instance to a team is just a team_id write, no re-mint required, which is exactly what removing forceNewInstance implies.

One gap I did not find covered here or in #2973 / #2648: deleting the channel does not reap what the deploy created. Both of my test channels were deleted from the relay; all 16 clone records survived in managed-agents.json and stayed invisible in Desktop. Even after forceNewInstance is removed, a deployment that is torn down still leaves its provisioned instances behind, and there is no UI path to see or remove them. Happy to file that separately if you would rather keep this issue scoped to the minting bug — say the word and I will.