Skip to content

feat(acp): surface agent permission requests instead of auto-approving #4938

Description

@Patrick-Erichsen

Motivation

When an ACP agent requests permission for a tool action, Buzz currently selects the first allow_once option automatically in crates/buzz-acp/src/acp.rs. That means an agent-proposed shell command can run without the Buzz user seeing the command or choosing a decision, even though ACP provides structured permission options. This is especially important for agents such as OpenClaw that use the permission request as their human safety checkpoint.

Proposed solution

Surface session/request_permission to the Buzz user with the sanitized action details and the exact options advertised by the ACP agent. Return the user-selected optionId to the agent. If Buzz needs an unattended mode, make automatic allow_once an explicit, visible per-agent policy rather than the unconditional default.

The normal default should fail closed when no user or configured policy can decide before the request expires.

Alternatives considered

  • Keep unconditional allow_once: simple, but bypasses the operator checkpoint requested by the agent.
  • Always reject: safe but makes tool-using ACP agents unusable.
  • Agent-specific handling: unnecessary because ACP already defines a generic permission request and response.

Additional context

Current behavior: crates/buzz-acp/src/acp.rs finds kind == "allow_once" and responds immediately, falling back to reject_once. OpenClaw native ACP emits these requests generically; this is not Buzz-specific protocol behavior.

Related integration work:

No matching open issue was found before filing.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions