[Bug] Desktop: no UI to set "start on app launch" for managed agents — built-in agents silently never autostart
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
### Summary
Managed agents have a persisted `start_on_app_launch` flag, but on macOS Desktop there is no reachable way for an owner to change it. Built-in agents (Fizz / Honey / Bumble) ship with the flag `false`, so after a full app quit they never come back on their own — the owner has to press **Start** on each one, every time. Agents created through the agent-draft flow get `true` and do autostart, so the two creation paths disagree.
Environment: Buzz Desktop **0.4.25**, macOS 26.5.2 (Darwin 25.5.0), Apple silicon.
### What the on-disk state looks like
`~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json` holds **two records per agent**: a definition (has `slug`, empty `pubkey`) and a live instance (real `pubkey`, no `slug`). Both carry `start_on_app_launch`; the one that actually governs startup is the **instance** record.
Before any intervention, on a workspace with three built-ins plus one draft-created agent ("Ticker"):
| record | slug | pubkey | `start_on_app_launch` |
|---|---|---|---|
| definition | `builtin:fizz` | — | `false` |
| definition | `builtin:honey` | — | `false` |
| definition | `builtin:bumble` | — | `false` |
| definition | `b0622424-…` (Ticker) | — | `false` |
| instance | — | `fc89d36d…` (Fizz) | `false` |
| instance | — | `0bf5144e…` (Honey) | `false` |
| instance | — | `7e7473da…` (Bumble) | `false` |
| instance | — | `e19e5b77…` (Ticker) | **`true`** |
Ticker autostarts; the three built-ins do not. Definition `false` + instance `true` is what a working agent looks like, which is why the definition record alone is not a useful place to write.
### Steps to reproduce
1. Fresh macOS install with the built-in agents; start Fizz manually so it is running.
2. Cmd+Q Buzz Desktop (full quit, not window close).
3. Reopen Buzz.
4. Fizz is not running. Same for Honey and Bumble. A draft-created agent in the same workspace comes up by itself.
### Expected
Either the owner can toggle "start on app launch" per agent from the UI, or built-in agents follow the same default as draft-created ones.
### Actual
No control found. The Edit-agent form's **Advanced** section contains only: *Who can talk to this agent*, *Parallelism*, *Instance name pool*, *Environment variables*. The owner also checked the agent list / card / Start–Stop area and found nothing.
The app does ship a Tauri command `set_managed_agent_start_on_app_launch` (JS parameter `startOnAppLaunch`), found via `strings` on `Contents/MacOS/buzz-desktop` — so the capability exists in the backend.
**Honest caveat about the negative claim:** I cannot prove no UI exists. Control test — the labels the owner can literally read on screen (`Instance name pool`, `Parallelism`, `Who can talk to this agent`) each return **0 hits** in the binary, so the embedded frontend is opaque to that method. What I can state is that the setting is undiscoverable to an owner who went looking for it. If the control does exist somewhere, pointing at it would be a fine resolution — and would suggest a discoverability bug instead.
### Workaround (for anyone hitting this)
With Buzz **fully quit**, set `start_on_app_launch: true` on the *instance* records in `managed-agents.json`, then reopen. The value survived the app's subsequent rewrite of the file, and all three agents came up unattended (verified by fresh `startedAt` timestamps in `agents/agent-pids/*.json`). Note that an agent cannot do this to its own app: managed agents are child processes of `buzz-desktop`, so the edit has to come from something detached from it.
### Suggested fix
1. Expose `set_managed_agent_start_on_app_launch` in the Edit-agent form (Advanced), next to *Who can talk to this agent*.
2. Make built-in agents default to the same value as draft-created agents, so a first-run workspace behaves consistently.
Related: #2501 — same file, same instance-vs-definition split, also a setting the owner cannot effectively change from the UI.
Contributor guide
Research direction
Start by locating the Rust implementation of `set_managed_agent_start_on_app_launch` and the Desktop Edit-agent form's Advanced section. Use `managed-agents.json` to verify that the instance record controls startup, then trace the built-in and agent-draft creation paths. Done means an owner can change the setting in the UI and built-in agents follow the intended startup behavior consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100