Desktop: side-panel "Delete agent" deletes only the agent instance, leaving the persona — the same button silently becomes "Start agent"

[0xnfrith]

Describe the bug

In the profile side panel that opens when you edit an agent, the destructive row labelled Delete agent does not delete the agent. It deletes only the keyed instance — which stops the process — and leaves the key-less persona definition in the store. The panel then re-renders with a Start agent button for the same name, and a second click of the same "Delete agent" row is required to actually remove it.

From the user's side this reads as: I confirmed a destructive "Delete agent" dialog, and all it did was shut the agent down. That is a dangerous shape for an action labelled and styled as destructive, and a confirm dialog that promises "Removes the local management record and saved agent key" / "Removes the agent from every channel it belongs to" is not describing what the first click does.

Steps to reproduce

1. Open an agent's profile side panel (edit an agent) as its owner.
2. Scroll to the destructive Delete agent row; confirm in the "Delete this agent?" dialog.
3. The agent stops. Reopen its profile — the name is still there, and the primary action is now Start agent.
4. Click Delete agent again — this time it actually deletes.

Expected behavior

One confirmed "Delete agent" removes the agent — instance and persona — or the dialog states plainly that only the running instance is being removed and the definition is kept.

Mechanism (code refs, origin/main @ eed74bd)

The store is unified: key-less definitions (former personas) and keyed instances live in the same managed-agents.json (managed_agents/storage.rs, load_managed_agents filters to !pubkey.is_empty(), load_agent_definitions to pubkey.is_empty()).

• delete_managed_agent (desktop/src-tauri/src/commands/agents.rs) stops the process, then retains-out only the matching keyed record. save_managed_agents deliberately re-reads and preserves the definition half (storage.rs:364), so the persona survives the delete. Correct on its own terms — but it is the whole of what the first click does.
• desktop/src/features/profile/ui/UserProfilePanel.tsx:718 — handleDeleteProfileAgent = viewerIsOwner && managedAgent ? handleDeleteAgent : handleDeletePersona. Same row, two different actions depending on whether an instance currently exists.
• UserProfilePanel.tsx:333 — canInstantiateAgent = isOwner && resolvedPersona !== undefined && managedAgent === undefined. After the instance is gone this flips true, and UserProfilePanelSections.tsx:415 renders ProfilePersonaPrimaryActions → Start agent.

So the button's identity changes underneath the user between click 1 and click 2, with no label or copy change to signal it.

Secondary finding (same flow)

desktop/src/features/profile/ui/UserProfilePanelDeletion.ts:89 hardcodes skipRemoteDeleteConfirm: true. The other delete path (useManagedAgentActions.handleDelete) passes no such flag, so it shows the "shutdown sent but the agent may still be running — deleting now orphans the remote deployment" confirms from deleteManagedAgentWithRules (managedAgentControlActions.ts:171-201). The side panel suppresses all of them. Same user-visible action, weaker orphan gate on the panel path.

Related

• Deletion of agents leaves residual configs creating confusion #5786 — relay-side residue after delete. Note its "Defect C: 12 of 48 rows have empty pubkey" is not corruption; those are the definition half of the unified store. The rest of that report stands.
• Provider-backed agent delete is routed through persona deletion and fails #3771 — provider-backed agent delete routed through persona deletion.

Version / platform

macOS (Apple silicon). Code analysed against block/buzz origin/main @ eed74bd. Behaviour observed in Buzz Desktop by the reporter; the delete path was not instrumented, so the code refs above are the mechanism that matches the observed sequence.