fix(desktop): explain open agent access

[daveh-beep]

Why

Hack-day feedback exposed a dangerous mismatch between the UI and the underlying access model. The Anyone respond-to mode appeared as a neutral dropdown choice, while a Buzz agent may act with the files, accounts, and tools available on the machine where it runs.

People reasonably read this as sharing a bot in a channel. The current UI did not explain that it can also share the agent's available access.

What

• Reframes respond-to as agent access in user-facing UI.

• Uses plain audience labels: Only me, Anyone, and Selected people.

• Warns for both sharing modes, not just Anyone — Selected people also hands host access to someone other than the owner, so only the audience phrase differs:

  Anyone can use this agent to access your computer, including files, accounts, and connected tools.

  Selected people can use this agent to access your computer, including files, accounts, and connected tools.

• Names the machine the agent actually runs on. A provider-backed (remote) agent reads:

  Anyone can use this agent to access the server it runs on, including any accounts and tools available there.

  The remote wording deliberately omits the owner's files — those aren't theirs to describe on a host they don't own.

• Places the warning below the selector for Anyone, but after the people picker for Selected people, so it never sits between the user and the selection they came to make.

• Removes Nostr, harness, pubkey, and !shutdown jargon from the primary decision copy. Direct pubkey entry remains available as an advanced path.

• Replaces the green open-access avatar dot with an amber warning marker and accessible text. Selected access uses a separate blue status.

• Aligns the sidebar action and profile field with the same language.

• Records the shared-field disclosure contract in desktop/src/features/agents/AGENTS.md so future surfaces do not silently omit it.

Design decisions

Persistent inline warning, not a confirmation modal. The setting does not autosave; the consequence remains visible beside the selection until the person chooses Save access. This gives the information before commitment without adding a dismiss-and-confirm ritual that would repeat in every create/edit surface.

An unknown run location falls back to the local wording. It does not hedge with "computer or server". A remote host requires an installed buzz-backend-* provider, and without one WhereToRunSection never renders — so "server" would name a concept the owner has never been shown. When it is remote, they picked that host from the selector themselves. Surfaces never synthesize a run location they don't have.

One resolution site, published through context. AgentDialog resolves the run location (runLocationForBackend from ManagedAgent.backend, runLocationForRunOn from the create flow's WhereToRunDraft) and publishes it via AgentRunLocationContext. It is not threaded as a prop through AgentDefinitionDialog (1047 lines) or AgentInstanceEditDialog (1228 lines) — neither uses the value, and both are already over the file-size ceiling. Surfaces outside that tree (EditRespondToDialog) pass the prop directly.

The copy follows the writing system's guidance for high-sensitivity decisions: lead with the material consequence, use plain actor/action language, keep helper text adjacent and persistent, and never rely on color alone.

Scope

Desktop only. The web and mobile clients do not currently expose this setting. No protocol, gate, runtime, persistence, or backend behavior changes.

This does not add team-scoped remote agents. It makes the current local-or-remote access model honest while that product work remains separate.

Validation

• pnpm exec biome check and pnpm exec tsc --noEmit — clean
• lib/agentAccessWarning.test.mjs (8/8) — every mode × run-location copy variant, both resolvers, unknown-reads-as-local, blank runOn is not a provider
• ui/respondToFieldContract.test.mjs (8/8) — plain labels, both warning positions, source-order guard that the allowlist warning follows the picker, helper-not-inline-copy guard
• agent-access-warning.spec.ts (3/3) — native local, provider-backed remote (asserts the server sentence and not "your computer"), persona-backed edit; includes a bounding-box check that the Selected people warning renders below the picker

[delkc]

Good to me from a content/UX perspective.

[klopez4212]

Wonder if the language should be even more of a warning that this allows people to access your computer..I know if says it but in relation to tools which softens the warning a bit in my eyes

[daveh-beep]

🤖 Addressed in 280ff48. The warning now leads with the direct consequence: “Anyone can send instructions to this agent and use it to access the computer or server where it runs.” I kept “computer or server” because agents may run remotely.

[daveh-beep]

🤖 @klopez4212 Here’s the final, one-sentence version for review.

Open access warning

Anyone will be able to access the computer or server running this agent.

[klopez4212]

@delkc to review again

[delkc]

Made some tweaks to the content so it recognizes whether the agent is running on your computer or a server, then just references the correct one. I also added the warning to the "Select people" option, since it's also true for the people you add there.

[tellaho]

lgtm