buzz-acp: make session/request_permission auto-response configurable (deny-by-default option)

[James-16]

Context

I'm embedding Buzz as a collaboration/audit layer in a supervised personal-automation setup, where agents connected over ACP must run fail-closed: a permission request that nobody explicitly approves should be rejected, not granted.

Current behavior (v0.5.2)

• crates/buzz-acp/src/config.rs defaults BUZZ_ACP_PERMISSION_MODE to bypass-permissions.
• handle_permission_request in crates/buzz-acp/src/acp.rs auto-approves the allow_once option when one exists, and falls back to reject_once only when no allow option is present.

So a stock deployment connected to a production environment will silently grant agent permission requests. For my use case that behavior is disqualifying without a patch — and the patch looks small, since the reject path already exists.

Request

A configurable auto-response for session/request_permission — e.g. extend the existing env var surface with something like BUZZ_ACP_PERMISSION_AUTO_RESPONSE=allow-once|reject-once (or an equivalent config key), so operators can choose deny-by-default without maintaining a fork. The default can stay as-is for backward compatibility.

Related: #2884 touches the same surface from the other direction (exposing more of the adapter's native permission modes); this request is about what buzz-acp itself does when asked, independent of adapter mode.

Happy to submit a PR if the direction is acceptable — the change looks contained to which branch of handle_permission_request wins, plus config plumbing and a test asserting allow_once is never auto-selected in deny mode.

[IgorGanapolsky]

Agree this should be operator-configurable, and that the default can stay bypass-permissions for backward compatibility.

A few correctness notes if anyone lands the PR (I am not claiming this issue — just mapping the surface):

1. Fail-closed must be the named mode, not an accident of option order. Today handle_permission_request prefers allow_once when present. A deny mode should select reject_once / cancel even when an allow option is offered by the adapter. Testing only “no allow option present → reject” leaves the common case open.

2. Auto-response is not the same as an adapter permission mode. buzz-acp: no way to select Claude Code's auto permission mode — adapter advertises it, PermissionMode omits it #2884 is about exposing native adapter modes; this knob is about what buzz-acp answers when the session asks. Keep them orthogonal so a harness can be acceptEdits while the bridge still denies unattended permission prompts.

3. Audit trail. When auto-responding (allow or deny), log the mode + chosen option id on the channel (or at least structured bridge logs). Silent auto-allow is exactly the failure shape that makes multi-agent coordination un-debuggable later — same class as accepted-but-ignored writes (Workflow deletion: non-owner delete is accepted then silently ignored, and owner delete leaves a ghost kind:30620 definition event #4580).

4. Env surface. Extending BUZZ_ACP_PERMISSION_MODE (or a sibling BUZZ_ACP_PERMISSION_AUTO_RESPONSE=allow-once|reject-once) is enough for v1; no need for a full policy engine. Document that unset = current behavior.

Happy to review a patch; the change really does look localized to the branch in handle_permission_request plus config plumbing and a unit test that asserts allow_once is never auto-selected under deny mode.

[James-16]

Confirming this appears resolved on main: as of 6ca9641, BUZZ_ACP_PERMISSION_MODE defaults to dont-ask, and handle_permission_request in crates/buzz-acp/src/acp.rs now selects reject_once (or the cancelled outcome) even when an allow_once option is offered — fail-closed in exactly the way this issue requested, including the correctness point raised in the earlier comment (deny must win despite an allow option being present, not only in its absence).

Verified by reading the source at that ref and running it self-hosted (no agent connected — verification was of the code path, not live ACP traffic). From my side this can be closed; leaving that to maintainers in case the remaining configurability (explicitly choosing an allow-mode) is still wanted as a separate knob.

[jcg-git]

Hit this today from the other side — a concrete unattended-agent use case that's currently unworkable because there's no configurability, not because fail-closed is wrong.

Setup: managed agent (runtime: codex, acp_command: buzz-acp, agent_command: codex-acp, mcp_command: buzz-dev-mcp) meant to run fully unattended as an adversarial plan reviewer. No human is watching the Activity pane to click Allow.

What I tried: set the agent's CODEX_CONFIG env var to {"approval_policy":"never","sandbox_mode":"workspace-write"}, assuming that would suppress permission prompts for its tool calls. Restarted, sent a real message. The Activity pane still shows Permission requested on a buzz-dev-mcp-routed shell call ("Read channel"), immediately followed by Denied (reject_once) — no human interaction, so this is the automatic path, not a missed click.

Traced why, confirming and extending the point already made above ("auto-response is not the same as an adapter permission mode... keep them orthogonal"):

• approval_policy only governs whether codex-acp decides to ask. Once session/request_permission reaches buzz-acp, handle_permission_request answers reject_once unconditionally (crates/buzz-acp/src/acp.rs:1895, :2017) — current behavior matches the confirmation above.
• The one partial adapter mode, acceptEdits (crates/buzz-acp/src/config.rs:117), only covers file edits — an MCP shell-tool call routed through buzz-dev-mcp isn't a file edit, so it's still denied.
• There's no per-agent escape hatch on the Desktop side either: CreateManagedAgentRequest/UpdateManagedAgentRequest expose env_vars, parallelism, respond_to, etc., but no permission-mode field (desktop/src-tauri/src/managed_agents/types/requests.rs:130, :200). BUZZ_ACP_PERMISSION_MODE is settable via env_vars (not in the reserved list, desktop/src-tauri/src/managed_agents/env_vars.rs:70), but the mode is only honored if the adapter advertises it, and any permission request that still arrives is rejected regardless (crates/buzz-acp/src/pool.rs:1017, :1149).

So right now there's no config-only way to run an MCP-tool-using Codex agent unattended in Buzz — which is the right default, but the deny-by-default request from the original issue (a real per-agent opt-in, not the old unconditional allow) is still the missing piece. Happy to test a patch against this exact repro (real Codex + buzz-dev-mcp session, not just source reading) if one lands.

[James-16]

@jcg-git's repro matches my reading of the current code — and it's a fair refinement of my note above: "resolved" was true for my deployment (I want unconditional deny), but the original request was for a configurable auto-response, and that half is still missing. Upstream shipped the right default; the per-agent opt-in for unattended flows remains open. +1 to keeping this issue open for that knob, with the constraints already mapped in this thread: deny stays the default, explicit opt-in only, audited auto-responses, and the unit test asserting allow-present ⇒ reject under deny mode.

[jcg-git]

Follow-up with a real answer to the "how does a Codex-runtime agent get unattended operation" question this thread left open (referencing my earlier comment above).

Codex has its own native pre-authorization mechanism, entirely outside buzz-acp. A Codex CLI session can define execution-policy rules in ~/.codex/rules/default.rules that pre-authorize specific command prefixes — when a command matches, Codex never emits a session/request_permission call in the first place, so it never reaches buzz-acp's reject_once handler at all. This is the same shape as Claude Code's own settings.local.json allow-list solving the identical problem for Claude-runtime agents — I'd missed that Codex has an equivalent, just under a different name/format.

Example, narrowly scoped to exactly what's needed:

prefix_rule(
    pattern = ["buzz", "messages", "send"],
    decision = "allow",
    justification = "Allow Buzz-managed agents to send Buzz messages",
    match = [
        "buzz messages send --channel channel-id --content hello",
    ],
    not_match = [
        "buzz messages get --channel channel-id",
        "buzz channels create --name example",
    ],
)

Confirmed working end-to-end: a real Codex-runtime managed agent, with this rule in place, now sends/reads/manages its own memory without any interactive approval, while unrelated write operations (channel creation, message edits/deletes, etc.) remain gated as normal.

One real gotcha worth flagging for anyone using this pattern: prefix_rule matches on the literal start of the executed command, not anywhere inside a pipeline. The common convention for multi-line/markdown content (printf '%s\n' "..." | buzz messages send --content -) does not match a rule scoped to ["buzz", "messages", "send"], since the actual command starts with printf. That's part of what motivated #5246 (--content-file) — a single direct command with no pipeline, so a plain prefix rule covers it cleanly.

Happy to write this up as a short doc/FAQ addition if that'd help others hitting the same wall — let me know if there's a preferred place for it.

[James-16]

This completes the picture nicely — and I think it's a better resolution than the knob this issue originally asked for. Pre-authorization in the runtime's own policy layer (Codex prefix_rules, Claude Code's allowlist equivalent) gives per-command scope with justification strings, while buzz-acp stays unconditionally fail-closed for everything else. Two layers, each doing the job it's best placed to do — versus a bridge-level env var that would flip the whole session's posture at once.

From my side (self-hosted, deny-always by preference) the original request is now fully addressed between the shipped default and this pattern: I no longer see a need for the bridge-level opt-in at all, though I'll defer to others on whether niche cases remain for runtimes without a native policy layer. +1 on the doc/FAQ offer — the printf-pipeline gotcha alone will save people hours, and this thread is currently the only place any of it is written down.