Describe the bug
A remote (provider-backed) agent whose process is dead still shows as online in its profile panel, and its primary action button stays Shutdown — so there is no way to bring it back from the UI. The same agent correctly shows as offline in the channel members sidebar at the same moment.
Root cause is one shared source-of-truth mistake in two places:
desktop/src/features/profile/ui/UserProfilePanelSections.tsx:192-198 — for a bot with a managed agent, the real presenceStatus is discarded and the avatar dot is derived from isManagedAgentActive(managedAgent) instead.
desktop/src/features/agents/lib/managedAgentControlActions.ts:34-41 — the primary action label uses the same helper.
isManagedAgentActive is status === "running" || status === "deployed", and for remote agents status comes from record.backend_agent_id.is_some() (desktop/src-tauri/src/managed_agents/runtime.rs:163-168), which is never cleared. So a provider agent is deployed forever, regardless of whether the process is alive.
By contrast desktop/src/features/channels/ui/MembersSidebarMemberCard.tsx:169-174 renders PresenceDot from the real relay presence — hence the contradiction between the two views.
Note the two-axis model itself is fine and documented (runtime.rs:145-163, docs/remote-agents.md:461): status = "does infrastructure exist", presence = "is the harness connected". The bug is that the UI reads the infrastructure axis where it needs the liveness axis.
Steps to reproduce
- Create a remote agent on a provider backend (reproduced with the Kubernetes backend).
- Let the agent exit — e.g. wait out
BUZZ_ACP_EXIT_AFTER_INACTIVITY (default 7200s, crates/buzz-backend-kubernetes/src/config.rs:35), so the pod completes (restartPolicy: Never).
- Look at the agent in the channel members sidebar → shows offline (correct).
- Open the agent's profile panel → avatar shows online, and the primary button reads Shutdown.
- There is no UI path to redeploy it.
Expected behavior
For provider-backed agents, both the profile avatar dot and the primary action should follow relay presence: offline agent → offline dot → Deploy button. deploy is already idempotent and normatively converges on a live instance (docs/remote-agents.md:875-879; the Kubernetes binding replaces a terminated pod — see terminated_pod_is_replaced_with_a_fenced_delete in crates/buzz-backend-kubernetes/src/reconcile.rs:849), so pressing Deploy would just work. Only the gating condition is wrong.
Version and platform
- Buzz version: 0.5.11 (code path verified unchanged in
main @ 69107dc3b)
- OS: macOS
Additional context
This currently blocks practical use of the Kubernetes provider: any agent that idles out is unreachable from the UI until the user edits managed-agents.json by hand to null out backend_agent_id.
Related but larger: it would be better still if mentioning an offline provider-backed agent redeployed it automatically, rather than requiring a manual button press. Happy to file that separately if it's wanted.
Describe the bug
A remote (provider-backed) agent whose process is dead still shows as online in its profile panel, and its primary action button stays Shutdown — so there is no way to bring it back from the UI. The same agent correctly shows as offline in the channel members sidebar at the same moment.
Root cause is one shared source-of-truth mistake in two places:
desktop/src/features/profile/ui/UserProfilePanelSections.tsx:192-198— for a bot with a managed agent, the realpresenceStatusis discarded and the avatar dot is derived fromisManagedAgentActive(managedAgent)instead.desktop/src/features/agents/lib/managedAgentControlActions.ts:34-41— the primary action label uses the same helper.isManagedAgentActiveisstatus === "running" || status === "deployed", and for remote agentsstatuscomes fromrecord.backend_agent_id.is_some()(desktop/src-tauri/src/managed_agents/runtime.rs:163-168), which is never cleared. So a provider agent isdeployedforever, regardless of whether the process is alive.By contrast
desktop/src/features/channels/ui/MembersSidebarMemberCard.tsx:169-174rendersPresenceDotfrom the real relay presence — hence the contradiction between the two views.Note the two-axis model itself is fine and documented (
runtime.rs:145-163,docs/remote-agents.md:461):status= "does infrastructure exist", presence = "is the harness connected". The bug is that the UI reads the infrastructure axis where it needs the liveness axis.Steps to reproduce
BUZZ_ACP_EXIT_AFTER_INACTIVITY(default 7200s,crates/buzz-backend-kubernetes/src/config.rs:35), so the pod completes (restartPolicy: Never).Expected behavior
For provider-backed agents, both the profile avatar dot and the primary action should follow relay presence: offline agent → offline dot → Deploy button.
deployis already idempotent and normatively converges on a live instance (docs/remote-agents.md:875-879; the Kubernetes binding replaces a terminated pod — seeterminated_pod_is_replaced_with_a_fenced_deleteincrates/buzz-backend-kubernetes/src/reconcile.rs:849), so pressing Deploy would just work. Only the gating condition is wrong.Version and platform
main@69107dc3b)Additional context
This currently blocks practical use of the Kubernetes provider: any agent that idles out is unreachable from the UI until the user edits
managed-agents.jsonby hand to null outbackend_agent_id.Related but larger: it would be better still if mentioning an offline provider-backed agent redeployed it automatically, rather than requiring a manual button press. Happy to file that separately if it's wanted.