Claude Code runtime always launches in dontAsk, preventing agents from executing commands

[Akthamix]

Describe the bug

After updating to Buzz v0.5.5, every Claude Code agent starts in dontAsk permission mode.

As a result, my agents can no longer execute shell commands. They silently fail because command execution is denied.

Running Claude Code directly from Terminal works correctly.

Steps to reproduce

1. Update to Buzz v0.5.5.
2. Configure an agent to use the Claude Code runtime.
3. Ask the agent to perform any action that requires running a command.
4. Open the Activity panel.

Actual behavior

The Activity panel shows:

Mode: dontAsk

The agent reports that it cannot execute commands because permissions are denied.

Example:

"permission to run commands is switched off in this session."

This prevents the agent from reading the repository, executing Git commands, or doing any normal development work.

Expected behavior

Buzz should either:

• Respect Claude Code's configured/default permission mode, or
• Allow selecting the permission mode (Auto, acceptEdits, bypassPermissions, etc.) for the Claude Code runtime.

At the moment, Buzz appears to always launch Claude Code in dontAsk.

Version and platform

• Buzz version: 0.5.5
• OS: macOS 15
• Hardware: Apple Silicon (M1 Max)

Additional context

Launching Claude Code manually from Terminal with:

claude --permission-mode bypassPermissions

works correctly.

The problem only occurs when Claude Code is launched through Buzz.

I've attached screenshots showing:

• Buzz Activity reporting Mode: dontAsk
• Claude Code working normally in bypassPermissions

[jayluxferro]

Getting the same issue here. @Akthamix thanks for raising the issue

[jds950]

Confirmed, also getting the same issue here on the latest software. Claude code works fine from the cli outside of buzz but cannot change the claude mode even from within the buzz terminal, stuck on " ⏸ manual mode on · ← 1 agent".

[Akthamix]

the only fix was downgrading back to v0.5.5

[daogrovelabs]

Also getting the same issue here after the update. The same issue for Codex and Kimi Code as well (Hermes is working though).

[jaozolins]

+1

[JVPartanen]

Still present on v0.5.7, and I have a same-agent before/after that pins the regression to the permission mode rather than anything about the agent or its config.

Log diff from one agent, one machine

buzz-acp logs its full startup line. Two runs of the same agent (same pubkey, same agent_cmd, same model, same everything else) — only permission_mode differs:

2026-08-07T09:03:39Z  … model=opus[1m] permission_mode=bypassPermissions respond_to=owner-only
2026-08-08T07:30:34Z  … model=opus[1m] permission_mode=dontAsk           respond_to=owner-only

On the bypassPermissions run the agent replied in-channel normally. On every dontAsk run since, it goes silent.

The user-visible symptom is worse than "commands are denied"

Because buzz messages send is itself a shell command, dontAsk doesn't just block tool use — it blocks the agent from publishing its reply at all. The turn completes, the text exists in stdout, and nothing ever reaches the channel.

From the channel side the agent looks like it ignored you. From the terminal it looks like it worked. Neither surface shows an error.

Confirming there is no publish attempt: grepping every agent log on this machine for messages send / buzz messages / failed to publish returns zero matches, while dontAsk appears 82 times.

This overlaps in symptom with #4709 / #3980 / #4923 (turn completes, reply never publishes) but the cause is different — those are the agent omitting the publish call, this is the harness denying it. Worth distinguishing when triaging, since a prompt-level mitigation (reinforcing buzz messages send in base_prompt.md or agent core memory) cannot fix the dontAsk case: the command is denied no matter how reliably the agent calls it.

Environment

• Buzz Desktop 0.5.7 (macOS, Apple Silicon)
• Runtime: claude-agent-acp, model=opus[1m]
• Relay: self-hosted, ghcr.io/block/buzz:sha-02f640b
• global-agent-config.json contains only env_vars, provider, model, preferred_runtime — no permission-mode field to set, so there is no user-facing way to opt out

Suggestion

Beyond exposing the mode in the UI (#4938), it would help to fail loudly: if a turn produces final text but no successful publish, log a warning and surface it in the Activity panel. Today the failure is completely silent on both surfaces, which is what makes it read as "the agent is ignoring me" rather than "the agent is not allowed to speak".

[iammienta]

Confirming this on macOS, and adding a same-machine before/after plus a confirmed workaround.

Environment: macOS 15 (arm64), Buzz Desktop 0.5.7 → rolled back to 0.5.5, @agentclientprotocol/claude-agent-acp 0.64.2, 4 managed Claude-runtime agents.

The default changed between 0.5.5 and 0.5.7

Straight from buzz-acp --help in each shipped bundle:

0.5.5

Defaults to `bypassPermissions` which skips the per-tool-call permission flow.
Set to `default` to restore the agent's built-in behaviour.

Possible values:
  - default:            Agent default — permission requests per tool call
  - accept-edits:       Auto-approve file edits, still ask for other tools
  - bypass-permissions: Skip the permission flow entirely
  - dont-ask:           Never prompt; reject anything that would require permission
  - plan:               Planning-only mode (no tool execution)

[default: bypass-permissions]

0.5.7

Defaults to `dontAsk`, which rejects operations that need interactive approval
because Buzz does not expose a human permission prompt.

Possible values:
  - default:      Agent default — permission requests per tool call
  - accept-edits: Auto-approve file edits, still ask for other tools
  - dont-ask:     Never prompt; reject anything that would require permission
  - plan:         Planning-only mode (no tool execution)

The default flipped and bypass-permissions was removed as a selectable value, so there is no longer any mode that permits Bash. That matters because Buzz's own injected prompt tells the agent to reply via the bundled CLI:

Hint: Use `buzz messages get --channel <UUID>` for recent messages if needed.
IMPORTANT: ... For ordinary replies in this turn, use `--reply-to <event-id>`

So 0.5.7 instructs agents to reply with buzz messages send while defaulting to a mode that denies the Bash call required to run it.

The failure is completely silent

buzz-acp only logs agent_returned on success, so a turn that dies at the permission layer leaves no log line at all. From the outside the agent looks connected, subscribed and online while answering nothing. I spent a long time chasing relay delivery before finding it — the agents were receiving fine the whole time.

The evidence is only visible in the agent's own session transcript:

>> printf '...' | buzz messages send --channel <uuid> --reply-to <event-id> --content "..."
<< Permission to use Bash has been denied because Claude Code is running in don't ask mode.

The agent diagnosed itself correctly:

"Your pings are reaching me; my replies are being stopped at the permission layer."

Negative result: settings.json allow rules do NOT override it

Worth recording so others don't lose time on the obvious workaround. I created a project-scoped .claude/settings.json in the agent's cwd:

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

In a session created after that file existed, a command literally beginning with buzz was still denied:

>> buzz messages send --channel <uuid> --content "pong — online and ready..."
<< Permission to use Bash has been denied because Claude Code is running in don't ask mode.

Broadening to allow: ["Bash"] made no difference either. The mode is applied by buzz-acp via session/set_config_option after session creation, so it stamps over whatever settings.json established.

Workaround that does work: roll back to 0.5.5

Same agent, same channel, same command, no config changes other than the version:

buzz messages send --channel <uuid> --reply-to <hex> --content "Pong — here and current..."
{"accepted":true,"event_id":"6c48c7c6b9d43d73c4b3e14ff58e2e36...","mention_pubkeys":[],"message":""}

Four consecutive failures on 0.5.7; first attempt succeeded on 0.5.5. On 0.5.5 the harness logs permission_mode=bypassPermissions and everything behaves as before.

Suggestion

If #4609's intent is that Buzz must never leave an unattended permission request hanging, that's reasonable — but it needs an opt-in escape for operators running their own agents on their own machines. Either restore bypass-permissions as a selectable value, or have dontAsk honour explicit permissions.allow entries from settings.json rather than rejecting everything unconditionally. As shipped, 0.5.7 makes Claude-runtime managed agents unable to perform their primary function, with no error surfaced anywhere in the Buzz UI or logs.

[skillz-xx]

Field confirmation from the same Buzz Desktop 0.5.7 installation, with an important root-cause distinction:

• Two owner-requested managed Claude review attempts were rejected under the unattended permission surface, including one explicitly read-only request. Desktop showed no approval UI.
• The same machine also had a separate managed Codex outbound failure: @agentclientprotocol/codex-acp 1.1.7 set ordinary Agent mode to workspaceWrite.networkAccess: false, so native buzz reads/sends failed with misleading DNS errors.
• After an exact-version, relay-host-scoped Codex adapter workaround and restart, a native buzz messages send returned accepted: true. Claude remained blocked.

That same-machine result rules out the relay, channel, signing identity, and bundled CLI as the cause of the Claude failure. The Codex shim is not a workaround for this issue; this issue remains a dontAsk / session/request_permission problem. #5262 and #5263 are the relevant tracker and proposed fix path.

One acceptance gate matters for #5263: test with the current Claude Code version in a fresh, untrusted nest and require both buzz --help and a signed buzz messages send to succeed. The workspace-trust caveat reported on that PR means a project-level .claude/settings.json allowlist should not be considered proven until that end-to-end test passes.

[Spec21four]

Same problem with all agents, both Claude and Codex. The problem arose when upgrading to version 0.5.7. Mac Mini M4

[charles-coderep]

Confirming on Windows 11, Buzz Desktop 0.5.7, Claude runtime (opus[1m]). Same symptom permission_mode=dontAsk in the start line, all shell tools denied, agent generates full replies that never reach the channel.

Also confirming 2 negative results on Windows:

• permissions.defaultMode: "bypassPermissions" in ~/.claude/settings.json is ignored
• agent_args: ["--permission-mode","bypassPermissions"] on the live agent row in managed-agents.json -- persisted across restarts, has no effect

I set the agent_command to a wrapper script to invoke claude.exe --permission-mode bypassPermissions %*
but caused the agent to fail to start entirely

[wolfyy970]

The immediate recovery is now in #5325. It stops forcing dontAsk, leaves each adapter in its normal permission flow, and answers the adapter’s offered allow_once request. That gets Claude and Codex agents working again without restoring blanket bypassPermissions; Goose receives no unsupported mode override.

The current head is mergeable and the real child/ACP wire regression passes. It is waiting on maintainer review.