Repository navigation
Provider-backed agent config saves do not trigger redeployment #2798
Description
Describe the bug
Saving configuration changes for a provider-backed managed agent updates managed-agents.json, but does not invoke the external provider again. The provider therefore continues running the previous configuration even though Desktop shows the newly saved value.
For example, changing a provider-backed agent from one model to another updates the model shown in Buzz Desktop, but subsequent mentions still execute with the old model until the provider is manually redeployed.
To reproduce
- Install an external
buzz-backend-*provider. - Create/deploy a managed agent through that provider with model A.
- Edit the agent in Buzz Desktop, change it to model B, and save.
- Send the agent another mention.
- Observe that the provider continues using model A.
Expected behavior
After a successful explicit save, Buzz should invoke the provider protocol’s idempotent deploy operation with the updated canonical agent record and provider config. The provider contract already defines repeated deploys as update-in-place/no-op, so a separate shutdown is not required.
Actual behavior
update_managed_agent persists the record locally but never calls deploy_to_provider. Provider deploy is currently reached by create/start paths only.
The Desktop Shutdown action is not a substitute for redeployment: provider protocol v1 has no shutdown operation, and the UI shutdown path sends !shutdown into a channel. It can also report “Cannot stop: agent is not in any channel” even when channel membership exists if the relay agent directory entry has no channel IDs.
Environment
- OS: macOS
- Buzz Desktop: v0.4.24
- Backend: external provider (
BackendKind::Provider)
Additional context
The provider protocol documents deploy as idempotent. The smallest fix is to invoke it after update_managed_agent completes its local save/profile-sync phase, and refresh the returned summary from the provider-updated record. Local agents should retain their existing next-spawn behavior.
Activity
jamesjlopez commentedon Aug 6, 2026
Additional evidence: this configuration/runtime drift also affects a local ACP-managed agent, not only provider-backed agents.\n\nEnvironment: Buzz Desktop 0.5.5 on macOS, local Codex ACP runtime. The Tech Lead profile/UI represented respond_to=anyone, but the deployed managed-agent record and repeated runtime startup logs showed respond_to=allowlist(1) with an obsolete Cloud Coder public key. James’s mentions were accepted by the relay with the correct Tech Lead p tag, but the runtime received no ACP prompt and silently dropped them at the author-policy gate.\n\nChanging the effective record to respond_to=anyone, restarting, and sending a new mention produced a visible ANYONE-OK reply. We also tested a description-only edit through Desktop: with auto_restart_on_config_change=true, saving the description caused an automatic stop/start even though the authorization control was untouched. In a clean state that restart preserved anyone, so the description edit alone was not sufficient to create the drift; it is an important redeployment boundary that can expose a stale canonical record.\n\nTakeaway: Desktop should show/verify the effective running authorization policy, keep the canonical/deployed/runtime records synchronized when any agent field is saved, and surface a diagnostic when a relay-accepted mention is rejected by the author gate. A health check or startup warning for stale allowlist identities would make this failure much easier to diagnose.