Allow hiding or disabling built-in personas (Fizz/Honey/Bumble) and the Welcome Team

[ella-zanette]

Problem

The three built-in starter personas (Fizz, Honey, Bumble) and the built-in Welcome Team cannot be removed from the Agents panel:

• validate_persona_deletion hard-rejects built-ins with "Built-in agents cannot be deleted."
• managed_agents/teams.rs similarly rejects built-in team deletion ("Built-in teams cannot be deleted.")
• Even if the stored records are removed from managed-agents.json externally, the loader re-seeds missing built-ins on every app launch, so they always come back.

Why this matters

For a self-hosted community running a curated roster of always-on agents (headless buzz-acp services on a server), the starter personas are permanent clutter in every device's Agents panel. They're dormant until someone clicks Start, but they:

• can't be distinguished at a glance from the "real" agents the team actually uses,
• invite accidental Start clicks that mint per-device agent copies (per-device duplicate identities are already a documented confusion source), and
• reappear after any cleanup, which reads as a bug to users who deleted them.

The starter personas are great for first-run onboarding — the request is only for a way to opt out after that.

Suggested behavior (any of these would solve it)

1. A "Hide" action on built-in persona/team cards that persists as a local tombstone and survives the re-seed pass, or
2. a settings toggle ("Show starter personas") defaulting to on, or
3. respecting deletion of pristine built-ins (the seed loader already distinguishes pristine vs customized copies for retired seeds — the same mechanism could honor a user tombstone).

Environment

• Buzz Desktop v0.5.8 (macOS, aarch64)
• Self-hosted relay (deploy/compose), closed membership
• Agents hosted headlessly via standalone buzz-acp launchd services

🤖 Generated with Claude Code

[drjconnorskehan]

I posted elsewhere, but at the very least they should allow access to the default agent's private keys so they can be reconfigured as true agents to be used in another capacity.

[cmyk]

A concrete UX defect makes this more confusing in Desktop 0.5.14:

The overflow action is labeled Delete for both custom and built-in personas, but the stock frontend deliberately executes different operations:

• PersonaActionsMenu.tsx: built-in → onDeactivate(persona); custom → onDelete(persona)
• AgentsView.tsx: onDeactivatePersona calls handleSetActive(persona, false, "library")

So for Fizz/Honey/Bumble, Delete does not delete anything. It silently means “deactivate/hide this seeded definition,” while the same label means real deletion for custom personas. The backend also re-seeds missing built-ins, so users reasonably conclude that Delete is broken when the trio remains or returns.

We reproduced the user-visible consequence while cleaning multiple unwanted instantiated starter identities by exact pubkey: after all instantiated Fizz/Honey/Bumble identities were safely removed, the three pubkeyless built-in definitions correctly remained—but the Agents UI still presented them as ordinary agents with a destructive-sounding Delete action. This collapses three different concepts into one surface:

1. built-in persona definition/template;
2. instantiated cryptographic agent identity;
3. active/running state.

Minimum UX fix:

• label the built-in action Hide starter agent or Deactivate template, never Delete;
• explain that it does not delete instantiated identities, memberships, keys, profiles, or signed history;
• reserve Delete for an operation that actually deletes the entity shown;
• ideally persist a built-in tombstone/opt-out so hidden starters stay absent, as proposed in this issue.

This is not just wording: the current label invites users to believe duplicate cryptographic identities were removed when only a local template flag changed.

[Matteo-Muscio]

Supporting information only, and a visibility bump for the maintainers: reproduced on Buzz Desktop v0.5.17 on macOS. After removing the local managed-agent instances and deactivating two starter personas, the last starter cannot be deactivated because the built-in Welcome Team references it; that team cannot be saved empty or deleted. This leaves the cleanup flow in a UI deadlock.

[WifiDan]

+1, same need here. Self-hosted community, running a curated roster of always-on agents headlessly (buzz-acp), same as the environment described above.

Compounding this with #5109: on our setup the built-ins have been silently re-minted multiple times over legitimate relay-URL edits during an infra migration, so we're not just stuck with one permanent Fizz/Honey/Bumble trio cluttering the Agents panel — we're stuck with several dead clusters we can't tell apart or remove. A "hide" tombstone (option 1) would solve both problems at once: it gets us out from under the clutter regardless of how many duplicate clusters the other bug produces in the meantime.

[jiwonschol]

Still reproduces on 0.5.23 (macOS, aarch64). Same shape of setup as the report: self-hosted relay, and the "real" roster now runs as headless buzz-acp systemd services on a VPS.

Verified today with the app closed: removed every built-in record from managed-agents.json, relaunched, and exactly one Fizz / Honey / Pollen was re-seeded. So the re-seed behaviour described above is unchanged.

Two data points that may help prioritise:

1. They accumulate. Before cleanup this install had 19 built-in records (7 Fizz / 6 Honey / 6 Pollen), which matches Signing out and back in re-provisions the built-in agents with new keypairs — duplicate same-named bots accumulate permanently in channels #4815 — each sign-out/sign-in re-provisions them. managed-agents.json was 725 KB; after removing them it is 131 KB.

2. The accidental-Start risk is now sharper. Our four real agents are backend: provider records (they execute remotely), so the built-ins are the only backend: local entries left in the panel. A stray Start on one of them is the only way this install can still mint a local agent process.

Option 2 from the suggestions (a "Show starter personas" toggle, default on) would be enough for this use case.

[jiwonschol]

Follow-up — there is a working workaround on 0.5.23, which I don't think is mentioned above.

Setting "is_active": false on the built-in records (app closed, edit managed-agents.json, relaunch) hides them from the Agents panel and survives the re-seed pass.

// managed-agents.json — for each of Fizz / Honey / Pollen
"is_active": false

Deleting the records does not stick (the loader re-seeds missing built-ins), but editing one does: the seed pass only appears to add records that are absent, not to reconcile fields on records that already exist. So a user edit survives where a deletion doesn't.

That is effectively suggestion 3 from the original report, already achievable — the built-ins are treated as customized rather than pristine. A supported "Show starter personas" toggle would still be better than hand-editing JSON with the app closed, but this unblocks self-hosted rosters today.

Verified on 0.5.23 (macOS, aarch64): three built-ins hidden, four provider-backed agents still listed normally.