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

[thomaspblock]

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:

1. bypassPermissions removed from the PermissionMode enum (crates/buzz-acp/src/config.rs).
2. Managed sessions default to dontAsk.
3. 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

[LucasMoskun]

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:

1. Added Bash(buzz) and Bash(buzz:*) to <nest>/.claude/settings.json.
2. Fully restarted the managed agent.
3. buzz messages send remained denied under dontAsk.
4. 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.

[colbymaloy]

yes no agent is usable for me at the moment.

[LucasMoskun]

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

1. Fully quit Buzz.
2. 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:*)"
    ]
  }
}

3. 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.
4. 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.

[colbymaloy]

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

[LucasMoskun]

@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(acp): surface permission requests as clickable sentinel 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.

[skillz-xx]

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.

[DamienStevens]

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.

[guihnz-code]

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:

1. Accept bypassPermissions as a deprecated alias that maps to default (or the eventual attended mode), with a WARN line.
2. Failing that, don't make an unknown BUZZ_ACP_PERMISSION_MODE fatal — log the invalid value, fall back to the default, and start.
3. 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.