[kazemek21]

TL;DR

Any agent running on this device can now read and change Buzz settings when you ask it to, through generic settings_list, settings_get and settings_set MCP tools. There is no per-agent switch and no UI change. The feature that owns each setting defines it once in a shared catalog and writes it through its own live setter, so the settings screen, storage and other windows see the change as if you had made it.

What agents can change

Key	Values	Owner
appearance.mode	system, light, dark	shared/theme/settings.ts
appearance.interface_size	80–200, steps of 10 (percent)	same
appearance.accent	the accent ids	same
appearance.vibe	low (Chillin’), high (Buzzin’)	same
conversations.thread_placement	side, main (new thread tabs only)	features/messages/thread-preferences.ts
conversations.follow_up_behavior	immediate, queue (Solo)	features/messages/follow-up-preference.ts
conversations.autocorrect	true, false (Mac message box)	features/messages/autocorrect-preference.ts
agents.remember_mentioned	true, false	features/messages/mention-preferences.ts

src/app/device-settings.ts composes the catalog. createDeviceSettings exposes one generic API (list, get, set) over string-enum, integer and boolean settings. Adding a setting means adding one definition, with no tool or router edits. Values must match exactly, with no aliases, case folding or clamping. Unknown keys, wrong types and extra arguments are refused, and nothing changes. Each write is read back. When storage refuses it, the answer is saved: false with the owner's own reason.

Not covered yet: Buzz has no shared settings store, so coverage follows which settings already have a synchronous setter that fits this shape.

• Notification preferences and keep-awake would each need an adapter, and notifications would also need services.ts construction order changed.
• Shortcuts take object values.
• Plugins' own settings, such as Focus, exist only inside the plugin.
• Excluded by design: actions such as sign-in, updates, leaving a community and clearing caches, as well as secrets, grants and consent, decision providers, models and anything destructive.

Who gets the tools

• Every agent run. An agent run's handle carries the catalog, and its Buzz MCP lists the three tools (load: "search"). Calls go through the same appClient check and signal as every other mutating Buzz tool, such as sending a message, and the write is synchronous after that check. A removed agent, a changed connection, or a turn the harness has ended or aborted changes nothing. Stop behaves as it does for those tools in each harness. Where the MCP connection outlives a stopped turn (Goose, and Claude Code without protection), a call already in flight when you press Stop can still land, as a message send can.
• Not plugins or external connections. A plugin's outside-run Agents.handle has no settings. Tools a plugin adds get the agent's client without settings. External MCP connections use that non-run handle and also get none.

Revision

An earlier revision gated this behind a per-agent, off-by-default Change Buzz settings switch in Agent details. It also added a settings-only Stop check to the Claude Code, Codex, Goose and Pi runtimes. Following product direction, both are removed. The AgentManage, AgentDetails, AgentsPage and ProfilePanel files, the agent record, and the four runtimes and Pi host are back to main. The earlier screenshots, how-to-try steps and the runtime and permission test evidence described that design and no longer apply.

Overlapping work

This PR does not build on any of these and changes none of their behavior:

• Authorize local apps to use Buzz MCP tools #2211: external auth and catalog.
• [3/5] Add protection to the Claude harness plugin #1878 and [5/5] Add protection to the Goose harness plugin #839 (now on main): Claude and Goose protection, whose pre-tool checks still review a settings call.
• Run native Codex through plugin execution targets #2150 and Run Codex sessions on plugin execution targets #2186: execution target.
• Add Appearance themes with a dark frame scope and the Relax theme #2180: themes. Theme selection is left out of the catalog.
• Preserve Solo queued messages across restarts #1704: queued follow-ups. This PR only exposes the existing behavior preference.

Validation

Run on a Blox Linux workstation against this exact tree:

• tsc --noEmit and biome on the touched files pass.
• vitest passes for 10 files (922 tests, after rebasing onto feat(plugins): let agents request plugin changes for owner review #2280). These are the changed tests, plus the Claude Code and Codex runtime tests and AgentManage, now back to main:
  • shared/device-settings: exact values, booleans, read-back, unsaved and closing.
  • app/device-settings: real createAppearance and the three message and agent preferences in jsdom, with persistence, change events and a refused setItem.
  • buzz-mcp: the catalog through the router, listing by connection, plugin tools without settings, and appClient checking the turn before each call.
  • features/agents/service: settings on every run's handle with no switch, none on a plugin's handle, and an aborted turn signal or agent removal while a call waits for review changing nothing.

No browser journeys were added or removed. Deferred: the native app hasn't been run with a live agent turn. The steps below cover that.

How to try it

1. Ask any agent running on this device to switch Buzz to dark mode. The app should switch at once, and Settings → Appearance should show Dark.
2. Ask it to open new threads in the main pane, then open a thread. It should open in the main pane, while open threads stay put.
3. Ask it to queue Solo follow-ups. Settings → Appearance → Follow-up behavior should show Queue.
4. Ask it for something outside the list, such as a theme. It should say that setting isn't available, and nothing should change.

🤖 Generated with Claude Code

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account.

Reviewed head 6d66406a55d11974307adf19edeb24fc51eaf6c3 against base 3858b55e6f91082f4536a6b1cb362121f5a4c800. Independent Guardians coverage: Rocket (harness lifecycle/persistence), Mantis (permission/correctness/security), Groot (product/accessibility), with Star Lord integration.

Two code findings are inline. One additional publication finding: [P2] Remove the internal initiative link from the public PR description. The “Initiative context” section links an internal project/status application. This repository and description are public, so the link exposes internal coordination metadata. Remove it or replace it with a public-safe description; the full internal URL is deliberately not repeated here.

Source-only review: no PR code, tests, builds, app or real harness runs executed. All six attached screenshots were inspected; no additional screenshot privacy finding. The one-time hosted check snapshot had 39 successful checks and 2 skipped. Live Stop timing, cross-window persistence, performance, keyboard focus during pending/error/retry, and screen-reader announcements remain unverified. This COMMENT is not approval or merge authorization.

[kazemek21]

Thanks for the review. On the description finding from the review body: agreed, and I've removed the internal initiative link from the PR description. The two inline findings are fixed in a59043c, with replies on their threads.

— Posted by Claude Code (claude-opus-5-5) on behalf of kylez

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account.

Reviewed head a59043c7b9f63beee27031674d95a1ffbe2c6813, base 3858b55e6f91082f4536a6b1cb362121f5a4c800, focusing on the four-file change since 6d66406a55d11974307adf19edeb24fc51eaf6c3. Rocket, Mantis and Groot completed independent lifecycle, correctness/security and product/accessibility lanes, with Star Lord integration.

The prior Stop-before-replacement bypass and missing permission-save alert are fixed in source, and the internal link has been removed from the public description. One fix-introduced P2 is inline. No additional publication finding after inspecting the current description and all six screenshots.

Source-only: no tests, builds, app or real harness execution. One-time hosted check snapshot: 39 successful, 2 skipped. The reported ordering is source inference; live Stop/restart timing, keyboard focus, screen-reader announcements and cross-window behavior remain unverified. This COMMENT is not approval or merge authorization.

[wesbillman]

🤖 Star Lord’s automated source review via Wes’s account, with independent Rocket, Mantis and Groot coverage. Follow-up to the review at a59043c; head bb0b998, base 3858b55.

The earlier Pi run-boundary and sequential recovery problems are addressed in this source. One existing P3 remains at the reviewed head, corroborated inline; no additional actionable findings. The author reports a fix in 3c44c22, which is outside this pinned revision and has not been assessed here. The separately discussed brief fail-closed overlap window remains a documented limitation.

Source and public PR material reviewed, including all six attached screenshots. No tests, builds, app launches or live harness workflows were run; CI, restart behavior, keyboard focus, screen-reader behavior and performance were not validated. This is a non-blocking COMMENT review, not approval.

[wesbillman]

🤖 Star Lord’s automated source follow-up via Wes’s account, with independent Rocket, Mantis and Groot coverage.

Reviewed head 5ba9782319c0d73d688cf6a0e42ae2381d978e12, base 0b2dfbf9889ea95873f175b216fbb0b5795f104e, focusing on the two-file change since bb0b99878828d6295aa26a6b34b4094c5c043f33.

No new actionable findings. The prior persistent settings refusal after Retry takes over an adopted request is addressed in source: the adopted receipt now leaves run membership by object identity after settlement, while request activity and reporting remain owned by the retry. The added regression covers recovery, retry without a new placement, settlement, and a fresh settings call. The previously discussed transient fail-closed overlap remains a limitation outside this fix.

The current public description and all six screenshots were inspected. Source-only review: no tests, builds, app launches or real harness workflows were run; CI, runtime recovery, keyboard focus, screen-reader behavior and performance were not validated. This COMMENT is not approval or merge authorization.

[wesbillman]

🤖 Star Lord's automated source review via Wes's account, integrating independent Rocket, Mantis and Groot coverage.

No new actionable findings in this follow-up at head 7e655ba (base/merge-base 1da5031).

Reviewed the prior permission/Stop fixes and their changed integration: owner-only permission, immediate revoke and failed-save behavior, catalog validation and synchronous setters, harness turn lifetime and cancellation, Goose's captured Stop policy, Pi run boundaries and receipt cleanup, and the Agents-page-only switch and error announcement. The description and all six attached screenshots were inspected.

Source-only review: no tests, builds, application or real harness runs, performance measurements, or CI verification. Native behavior, keyboard focus recovery, assistive technology behavior and human acceptance remain unverified. This COMMENT is not approval or merge authorization.

[kazemek21]

🤖 One change since the approval at 2edb2d6, from rebasing onto main after #839 (Goose protection):

• Goose now reviews tool calls in its own pre-tool check before they reach Buzz, as Claude Code does after [3/5] Add protection to the Claude harness plugin #1878. Buzz skips its own review of an unchanged settings call, so nothing waits between pinning the turn and the write.
• I reverted the Goose-only Stop capture added for that review window, so Goose's turn policy matches Claude Code's. I replaced its test with one that refuses a settings call from a reply delivered into a turn the owner stopped. That test fails without the policy's handling of the earlier turn.

Biome, tsc and vitest over src/buzz-mcp, src/features/agents, src/features/agent-harness, src/bundled, src/app and src/shared pass on a Blox Linux workstation. Head: c57c90328.

— Posted by Claude Code (claude-opus-5-5) on behalf of kylez

[kazemek21]

🤖 Scope changed since the last reviews, following product direction. Settings are now an ordinary Buzz MCP capability for every agent run, not something switched on per agent:

• Removed the per-agent Change Buzz settings switch, its stored permission and allowSettings. AgentManage, AgentDetails, AgentsPage, ProfilePanel and the agent record are back to main.
• Removed the settings-only Stop check from the Claude Code, Codex, Goose and Pi runtimes and the Pi host, all now back to main. Settings calls use the same appClient turn check and signal as the other mutating Buzz tools.
• The catalog now exposes one API (list, get, set) and supports booleans. It also adds Solo follow-up behavior, autocorrect and remembering mentioned agents, each defined by its own feature. Plugins and external connections still get no settings.

The earlier screenshots and permission/runtime evidence no longer apply. The description is updated, including what isn't covered yet. Head 10c6caf passes tsc, biome and 920 targeted vitest tests on Blox.

— Posted by Claude Code (claude-opus-5-5) on behalf of kylez