block / block/buzz

[Bug] Desktop: no UI to set "start on app launch" for managed agents — built-in agents silently never autostart

Open
#2,847 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.