Managed agents can't run the bundled buzz CLI after #4609 — all permission requests rejected under dontAsk

Summary

After #4609 (fix(acp): reject unattended permission requests, commit ad538bfb1, merged 2026-08-05), desktop-managed agents whose runtime raises a session/request_permission for the bundled buzz CLI are unconditionally denied — every buzz invocation, including buzz --help, fails. Since buzz is the agent's only interface to the relay (reading channels, sending replies), an affected agent cannot perform its primary function.

Report

An X user reported (screenshot relayed in the buzz-bugs channel): a managed agent ("Growth", Claude Code runtime, Mode: dontAsk) says:

I can't reach the buzz CLI in this session — every buzz command (even buzz --help) is being auto-denied by permission settings, while other Bash commands go through fine. That blocks me from reading the channel history or sending a reply.

Root cause

#4609 intentionally made the harness fail closed:

bypassPermissions removed from the PermissionMode enum (crates/buzz-acp/src/config.rs).
Managed sessions default to dontAsk.
handle_permission_request (crates/buzz-acp/src/acp.rs) now answers every session/request_permission with reject_once (or cancelled) instead of the old allow_once auto-approval.

The commit's operator notes predicted this exact failure:

"Desktop managed agents do not set a permission mode, so they inherit dontAsk. The desktop has no permission prompt, so operations needing approval now fail with no in-app way to approve them."

Why only buzz is affected: the agent runtime (e.g. Claude Code) only raises permission requests for tool patterns not pre-authorized in its own local settings. Common shell commands are covered by the runtime's allowlist and never ask; the buzz sidecar binary is not, so every invocation asks — and the harness now rejects all asks.

Impact

Severity: high for managed agents on affected runtimes/configs — the agent is cut off from the relay entirely (cannot read, cannot reply), while appearing "online".
The failure is confusing to end users: the agent blames "permission settings" with no in-app way to see or fix anything.

Proposed fix (narrow, preserves fail-closed posture)

Pre-authorize the bundled buzz CLI for managed sessions, so the platform's own sidecar is never subject to the reject-all path, while all other permission requests keep failing closed. Candidate mechanism: seed the managed agent runtime's local pre-authorization (e.g. Claude's settings.json permissions.allow for Bash(buzz *) / the resolved sidecar path) at nest creation — #4609 explicitly scopes agent-side pre-authorization as outside the harness guarantee, so this does not reopen the auto-approval hole.

Longer term: a desktop permission prompt so dontAsk is not the only reachable mode (also called out in #4609's operator notes).

References

fix(acp): reject unattended permission requests #4609 / commit ad538bfb1e6bfebcb03afaf4dd4d22323e7e62bd
crates/buzz-acp/src/acp.rs — handle_permission_request / permission_denial_response
crates/buzz-acp/src/config.rs — PermissionMode
crates/buzz-acp/src/pool.rs — apply_permission_mode, agent_supports_mode

Additional deterministic reproduction from Buzz Desktop 0.5.6 on macOS, using a locally managed Claude agent against a self-hosted relay and Claude Code 2.1.220:

Added Bash(buzz) and Bash(buzz:*) to <nest>/.claude/settings.json.
Fully restarted the managed agent.
buzz messages send remained denied under dontAsk.
A fresh headless Claude invocation from the same nest printed:

Ignoring 2 permissions.allow entries from .claude/settings.json: this workspace has not been trusted.

Current Claude Code treats project-level permissions.allow entries as capability grants and does not apply them until workspace trust is accepted. The Buzz headless ACP flow cannot present that trust dialog.

Moving the identical rules to <nest>/.claude/settings.local.json fixed the failure. A fresh invocation using --permission-mode dontAsk --setting-sources user,project,local executed buzz --help successfully and returned permission_denials: []. After restarting Fizz, the effective harness was claude-agent-acp, model claude-fable-5[1m], and the agent connected to the intended self-hosted relay.

This means the narrow workaround is valid, but the settings source matters on current Claude Code. PR #5263 currently seeds .claude/settings.json; the implementation likely needs .claude/settings.local.json or another headless-safe trust mechanism.

yes no agent is usable for me at the moment.

@colbymaloy

@colbymaloy I reproduced this and have a working temporary recovery for Claude-managed agents while #5263 and #5106 are pending.

Fully quit Buzz.
Create or conservatively merge this file:
- macOS/Linux: ~/.buzz/.claude/settings.local.json
- Windows: %USERPROFILE%\.buzz\.claude\settings.local.json

{
  "permissions": {
    "allow": [
      "Bash(buzz)",
      "Bash(buzz:*)"
    ]
  }
}

Use settings.local.json, not settings.json. Current Claude Code may ignore project settings.json allow rules until workspace trust is accepted, and the headless Buzz session cannot show that trust dialog.
Reopen Buzz and fully restart the managed agent.

This narrowly restores the bundled buzz CLI so the agent can read channels and reply. I validated it under dontAsk with Claude Code 2.1.220 on macOS against a self-hosted relay.

Git, file edits, and other tools can still be denied; that broader UX is what #5106 addresses. Avoid adding bare Bash unless you intentionally want to grant the agent unrestricted shell access as your OS user.

I rechecked #5263 immediately before posting this: it is still open and its current implementation still seeds .claude/settings.json, so this local workaround remains relevant. If you are using Codex rather than Claude, or this does not work, post your OS, Buzz version, and effective harness command (claude-agent-acp versus codex-acp) and we can narrow it down.

@LucasMoskun

im using both codex and claude on mac os, the latest buzz version it allowed me to update to.

the claude fix worked, but would love to get codex working too as i let them argue about a product's plan @LucasMoskun

@colbymaloy

@colbymaloy I checked the Codex side against the adapter bundled with the current Buzz release (codex-acp 1.1.7).

The temporary Codex workaround is to launch it with:

INITIAL_AGENT_MODE=agent-full-access

I directly verified that this makes a new Codex ACP session report currentModeId: agent-full-access, and that it can execute buzz --help successfully with exit code 0 without raising a permission request or denial.

I have not yet completed the final end-to-end test of sending a relay message from a Buzz Desktop-managed Codex agent, because my active Buzz agents are in use right now. Based on the adapter behavior, though, I’m reasonably confident this should unblock Codex until the next Buzz update/fix.

A few important notes:

Fully quit/reopen Buzz and restart the managed agent after adding the variable; it is read when codex-acp starts.
Confirm the startup log says agent_cmd=.../codex-acp. Because of Agents are referencing old instance with outdated harness #5054, a stale runtime override can leave the agent launching claude-agent-acp, in which case this Codex setting has no effect.
agent-full-access is intentionally broad: Codex runs without approval prompts and has unrestricted filesystem and network access as your OS user. Only use it for agents/workspaces you trust.
Treat this as a temporary workaround while feat(desktop): surface tool-permission asks as thread-reply cards (#4938) #5106/Managed agents can't run the bundled buzz CLI after #4609 — all permission requests rejected under dontAsk #5262 are being resolved.

If the mode still fails after a full restart, please paste the buzz-acp starting: log line (with secrets removed) and we can tell whether Buzz actually launched the expected harness.

Same-machine confirmation from Buzz Desktop 0.5.7:

Two owner-requested managed Claude review attempts were rejected under the unattended permission surface, including one explicitly read-only request. Desktop displayed no approval card.
This machine concurrently had a separate managed Codex adapter regression. After repairing that network-policy path, a native buzz messages send succeeded with accepted: true.
Managed Claude still could not run the requested review.

That sequence is useful isolation evidence: the relay, channel, signing identity, and bundled CLI were healthy; the remaining Claude failure is the dontAsk / session/request_permission path described here. The exact-version Codex network shim is not a workaround for this issue.

For #5263, I recommend treating the acceptance condition as an end-to-end managed Claude test using the current Claude Code version and a fresh, untrusted nest: buzz --help must run and a signed buzz messages send must return accepted: true, without a manual trust dialog. The workspace-trust result already reported on #5263 means a project-level .claude/settings.json allowlist should not be considered sufficient until that test passes; the reported .claude/settings.local.json behavior is important to verify in the product test.

@LucasMoskun

Independent confirmation of @LucasMoskun's settings-source finding, with the --setting-sources confound removed — relevant to #5263, which currently seeds .claude/settings.json.

That verification used --setting-sources user,project,local explicitly. The flag can itself change which files are honored, so it leaves open whether settings.local.json is genuinely trust-exempt or was merely force-loaded. I re-ran it with default setting sources — what the headless flow actually uses — isolating the filename as the only variable.

Method. Two scratch directories, neither with a hasTrustDialogAccepted entry in ~/.claude.json. Identical rule in each, differing only in filename. Same CLI, same invocation, no --setting-sources:

<nestA>/.claude/settings.json        { "permissions": { "allow": ["Bash(touch:*)"] } }
<nestB>/.claude/settings.local.json  { "permissions": { "allow": ["Bash(touch:*)"] } }

claude --permission-mode dontAsk -p 'Run bash: touch <file>'

Result.

File	Untrusted workspace	Outcome
`.claude/settings.json`	rules ignored	`touch` denied, no file created
`.claude/settings.local.json`	rules applied	`touch` allowed, file created

settings.json emitted Ignoring 1 permissions.allow entry from .claude/settings.json: this workspace has not been trusted. — settings.local.json emitted no warning.

The trust gate keys on the settings source, not the directory. This confirms settings.local.json is the correct target for #5263: seeding settings.json is silently inert for any nest never opened interactively, which is every desktop-managed nest.

The alternative works and is worse. Setting projects["<nest>"].hasTrustDialogAccepted: true in ~/.claude.json does make settings.json take effect (verified on the same machine). Not recommended as the shipped fix: ~/.claude.json is rewritten by Claude Code itself, so the grant can disappear and the agent silently reverts to muted with no signal on any surface. settings.local.json carries no such dependency.

One more thing for whoever implements the seed. Granting only Bash(buzz:*) restores the send path but not the agent. Under the previous bypassPermissions default these agents also ran git, gh, yt-dlp, uv, wrote files, and read paths outside the nest — all of which now need Read/Write/Edit and permissions.additionalDirectories entries. A buzz-only grant leaves agents able to speak but not to work, which will land as a second, subtler regression report.

Environment

Buzz Desktop 0.5.7, macOS 15 (Apple Silicon)
@agentclientprotocol/claude-agent-acp 0.63.0
Claude Code CLI 2.1.226 (regression boundary observed on this machine between 2.1.224 and 2.1.225, but the causal change is the harness default, not the CLI — see below)
Harness claude-agent-acp, permission_mode=dontAsk in the buzz-acp starting: line; the same agent logged permission_mode=bypassPermissions on every launch before the desktop upgrade
Self-hosted relay, ghcr.io/block/buzz@sha256:3dfc3a4b54411c8dc398e9c61f4a1079d67e224e9c3b27f744a6ef0850d14d8f, image label org.opencontainers.image.revision = 3855687e7699f1b169f179122b8bc92f433abd6d. NIP-11 reports version: 0.2.0, which is buzz-relay's CARGO_PKG_VERSION and says nothing about the deployed commit — worth knowing when triaging reports that suspect the relay.

Relay-side evidence that the relay is not implicated (adds to @CarsonStevens' point on #5260): querying the relay's event store for a failed turn shows the agent's kind-7 reaction markers and their subsequent kind-5 deletions both accepted and stored. Only the kind-9 reply is missing — because it was never attempted. The agent's write path to the relay is healthy throughout; the harness simply never lets it run the command. That signature — reactions present, reply absent, no error anywhere — is a reliable way to distinguish this bug from a genuine relay or delivery fault.

@mkelowna

Migration trap: the value 0.5.6 logged as its own mode is now a fatal argument

Adding one narrow finding that isn't in this thread or in #5303 — the obvious operator workaround for this issue kills the seat outright, with no in-app error.

Buzz Desktop 0.5.7, macOS, managed Codex agent (codex-acp 1.1.7), self-hosted relay. Reading the bisect in my own harness logs (~/Library/Application Support/xyz.block.buzz.app/agents/logs/), pre-update startup on this seat logged:

2026-08-08T02:38:11Z INFO buzz_acp: buzz-acp starting: ... model=gpt-5.5 permission_mode=bypassPermissions
2026-08-08T04:25:55Z INFO buzz_acp: buzz-acp starting: ... model=gpt-5.5 permission_mode=dontAsk

mtime of /Applications/Buzz.app sits between the two, so the mode flip is the update.

The natural reading of that log is "restore the previous mode", so I set BUZZ_ACP_PERMISSION_MODE=bypassPermissions in the agent's env_vars. The seat then fails to start at all:

=== starting <agent> (<pubkey>) at 2026-08-08T13:34:18Z ===
error: invalid value 'bypassPermissions' for '--permission-mode <PERMISSION_MODE>'
  [possible values: default, accept-edits, dont-ask, plan]

For more information, try '--help'.

One fatal start per launch attempt, across 6 log files (2 agents × 3 relays). Desktop showed a generic agent error card — nothing naming the argument. Removing the variable brings the seat back up (permission_mode=dontAsk, connects to the relay normally).

Why this is worth a line in the fix: #4609 removed bypassPermissions from the enum, but the string is still what every pre-0.5.7 log line, and every pre-0.5.7 runbook, calls the working state. Anyone who pinned it — via env_vars or the launchctl setenv route described in #5303 — upgrades into a seat that never starts, and the only place the reason appears is a log file.

Suggested handling, in order of preference:

Accept bypassPermissions as a deprecated alias that maps to default (or the eventual attended mode), with a WARN line.
Failing that, don't make an unknown BUZZ_ACP_PERMISSION_MODE fatal — log the invalid value, fall back to the default, and start.
Either way, surface the argument-parse error in the Desktop agent card, not only in the log.

Separately, thanks for the INITIAL_AGENT_MODE=agent-full-access note above — I'd reached the same switch from the adapter source, and can confirm INITIAL_AGENT_MODE appears 0 times in strings /Applications/Buzz.app/Contents/MacOS/buzz-acp, while the same binary does contain injecting CODEX_CONFIG network_access for relay host and {"sandbox_workspace_write":{"network_access":true}}. So on the Codex side Buzz writes the fix into the one knob the adapter ignores, and never touches the one it reads — consistent with @mkelowna's analysis in #3031 and with agentclientprotocol/codex-acp#361.

Additional verified 0.5.7 reproduction from an Apple Silicon Mac mini, including a same-agent before/after timeline and impact beyond the bundled CLI.

Same managed agent across the upgrade boundary

Fizz's startup log shows:

2026-08-06T18:30:05Z  permission_mode=bypassPermissions
2026-08-08T01:08:46Z  permission_mode=dontAsk
2026-08-08T10:13:56Z  permission_mode=dontAsk
2026-08-08T10:33:49Z  permission_mode=dontAsk
2026-08-08T12:04:53Z  permission_mode=dontAsk

The installed app is Buzz Desktop 0.5.7. Across the local managed-agent logs:

9/9 agents relaunched after the update show dontAsk on their latest launch.
4/4 agents whose latest launch remained from before the update still show bypassPermissions.
No per-agent permission field was found in the managed-agent records or available pre-upgrade backup.

This rules out an individual Fizz setting and strongly supports an upgrade/restart migration boundary.

Impact extends beyond `buzz messages send`

The same fail-closed path also rejected approval-gated Computer Use. Buzz Desktop displayed no approve/deny prompt, and changing the launch mode to default did not provide a usable owner decision path because session/request_permission was still resolved by the harness rather than surfaced to the owner.

The owner reports the same post-update loss of Computer Use on a separate MacBook. I have not independently retrieved that host's exact logs, so this is cross-host corroboration rather than part of the verified packet.

Desired durable behavior

The emergency revert in #5323 restores function, but the durable product need remains:

default should surface an owner-visible approve-once/deny decision for session/request_permission, or use an explicit least-privilege per-agent policy.
dontAsk should remain an explicit fail-closed option with an actionable UI explanation.
Upgrades should not silently migrate existing agents from working capability to an unresolvable denied state.
Directly addressed turns that cannot publish because of permission policy should not report a clean ok outcome.

This aligns with the owner-facing policy work in #4938/#5106 and the silent-turn report in #5322. The local 0.5.7 settings and agent records were not modified during diagnosis.

docs(acp): correct the allow-rule claim — trust gate, not mode override

fix(desktop): seed nest Claude settings with buzz CLI allowlist

Same behavior here with a desktop-managed agent (Claude Code runtime, Buzz app). It processes tasks correctly (visible in the agent's activity log) but the reply never reaches the channel. Consistent with the dontAsk auto-reject described above.

Recurring even after the update that seemed to fix it (see my earlier comment). Today the agent read the file correctly and produced the full report (visible in the agent's activity panel) but never posted the reply to the channel.

Navigation Menu

Repository navigation

Managed agents can't run the bundled buzz CLI after #4609 — all permission requests rejected under dontAsk #5262

Summary

Report

Root cause

Impact

Proposed fix (narrow, preserves fail-closed posture)

References

Migration trap: the value 0.5.6 logged as its own mode is now a fatal argument

Same managed agent across the upgrade boundary

Impact extends beyond `buzz messages send`

Desired durable behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Managed agents can't run the bundled buzz CLI after #4609 — all permission requests rejected under dontAsk #5262

Description

Summary

Report

Root cause

Impact

Proposed fix (narrow, preserves fail-closed posture)

References

Activity

LucasMoskun commented on Aug 8, 2026

colbymaloy commented on Aug 8, 2026

LucasMoskun commented on Aug 8, 2026

colbymaloy commented on Aug 8, 2026

LucasMoskun commented on Aug 8, 2026

skillz-xx commented on Aug 8, 2026

DamienStevens commented on Aug 8, 2026

guihnz-code commented on Aug 8, 2026

Migration trap: the value 0.5.6 logged as its own mode is now a fatal argument

JRStriestocode commented on Aug 8, 2026

Same managed agent across the upgrade boundary

Impact extends beyond buzz messages send

Desired durable behavior

tomfigueiredomaia commented on Aug 25, 2026

tomfigueiredomaia commented on Sep 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Impact extends beyond `buzz messages send`