Self hosted relay update on 2026/08/07 or client update causes Claude Code agents to fail completely

[apatrida]

Describe the bug
All tool calls rejected for Claude by harness, says it is running in "Don't ask mode" even though the launch command is clearly not that. Apparently it is not responding correctly to callbacks and this confuses the harness.

Steps to reproduce

1. upgrade your relay docker compose today and pray (./run.sh upgrade)
2. do anything with a claude code agent
3. it never responds because all shell commands fail

Expected behavior
Claude to still work.

Version and platform
Find your version at the bottom of the Settings sidebar. Write "unknown" if you can't determine it.

• Buzz version: 0.5.6 client, 2026-08-07 images from docker compose
• OS: linux

Logs / additional context
...

Smoking gun confirmed. The fresh session's effective runtime state:

"permissionMode":"dontAsk"      ← effective mode
"entrypoint":"sdk-ts"           ← buzz's TypeScript Agent SDK

The process was launched with --permission-mode bypassPermissions, but the SDK is running the session in dontAsk mode. That's the whole bug in one field. dontAsk = auto-deny anything that would otherwise prompt. The CLI flag is overridden by what buzz's SDK passes over the control channel.

Final verdict

This is a buzz bug from the upgrade — you called it. buzz's sdk-ts harness now initializes sessions with permissionMode: 'dontAsk' (or omits the approver so the SDK falls back to it), which supersedes the --permission-mode bypassPermissions launch flag. Every tool call auto-denies; since buzz messages send rides on Bash, agents go completely mute at the first call — exactly the "jail."

Everything else is cleared, with proof:
- Not Anthropic / not retribution — the "403" was the session-id prefix, no server rejection anywhere.
- Not subscription — I ran buzz's exact flags on pure subscription → pong, zero denials.
- Not auth at all — the model responds fine; only tool execution is gated.
- "API key works" is a confound — those agents moved to opencode's harness, which sets the mode correctly. It's the harness, not the credential.
- Restart never could've fixed it — it's code, not process state.

Fixes

Durable (buzz-side, the real fix): buzz must pass permissionMode: 'bypassPermissions' in its SDK query() options — or supply a canUseTool that approves — instead of letting it default to dontAsk. File it against the upgrade / downgrade buzz until patched.

[apatrida]

buzz's sdk-ts harness now initializes sessions with permissionMode: 'dontAsk' (or omits the approver so the SDK falls back to it), which supersedes the --permission-mode bypassPermissions launch flag.

nice...

[CarsonStevens]

Additional reproduction with a materially different deployment from the original report.

Client setup

• Buzz Desktop 0.5.6
• Windows 11 Home x64, build 26200
• Managed Claude Code agent through the bundled buzz-acp.exe
• Claude Code 2.1.224
• Effective permission mode shown by the failure: Don't Ask / dontAsk

Relay/server setup

• AWS ECS/Fargate in us-west-2
• One desired/running task; deployment is complete and the task is healthy
• Task definition: topline-dev-buzz:4 (0.5 vCPU / 1 GiB)
• Image: ghcr.io/block/buzz@sha256:5ac4697562230d32de4473d2eaf2eab098300c8aae1721e6bd4bf00b2956a5bf
• Image metadata points to upstream revision 63496cc1d4c6f1b7c613801bdcc694169dcf391a, built 2026-07-30
• Postgres, Redis, and S3-backed deployment behind an ALB
• Both relay and pairing targets report healthy; returns HTTP 200 ok

Reproduction

A Claude Code agent attempted this read-only channel-history command:

buzz messages get --channel <channel-id> --limit 200 2>&1 | head -200

Buzz displayed this error before the command could execute:

Permission to use Bash has been denied because Claude Code is running in don't ask mode.

This confirms the failure affects read-only Buzz CLI operations, not only sends: the agent cannot retrieve channel context because the Bash tool request is rejected immediately.

The server is healthy and pinned to an image built July 30 rather than a fresh August 7 image. That makes the Desktop 0.5.6 / buzz-acp session permission-mode path the stronger common factor in this reproduction; the relay upgrade described in the original report is not required to trigger it.

[ladissi]

Confirming on macOS, Buzz Desktop, hosted relay at buzz.xyz. Same symptom, agents produce replies but every Bash call is denied so nothing reaches the relay.

Partial workaround that unblocks the CLI without waiting for a patch, in ~/.claude/settings.json:

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

Allow rules are evaluated before the permission mode, so they survive dontAsk. The limitation is that they only match the bare command. buzz feed get --limit 5 runs, but buzz feed get --limit 5; echo $? is still denied, since the shell operator means it no longer matches the rule. Agents that chain commands or pipe into other tools keep failing.

[JPC-Matt]

Confirming this is still present in 0.5.7 (macOS desktop, self-hosted relay), and sharing a workaround that doesn't require bypassPermissions.

Evidence from harness logs across the update boundary (same agent, same config, no user changes — hostname/pubkeys redacted):

2026-08-07 ... buzz-acp starting: ... permission_mode=bypassPermissions respond_to=owner-only
2026-08-08 ... buzz-acp starting: ... permission_mode=dontAsk respond_to=owner-only

After the update every tool call is auto-denied, so agents appear alive but can't execute anything — matching the OP.

Workaround that avoids the bypass footgun: dontAsk only denies tools that aren't pre-approved. Claude Code loads permission rules from <harness cwd>/.claude/settings.json, and the desktop harness runs with cwd ~/.buzz. So:

1. Create ~/.buzz/.claude/settings.json with an explicit allow/deny list, e.g.:

{
  "permissions": {
    "allow": ["Read", "Grep", "Glob", "Write", "Edit", "WebFetch", "Task", "Bash(git:*)", "Bash(buzz:*)"],
    "deny":  ["Bash(rm:*)", "Bash(sudo:*)"]
  }
}

2. Mark the workspace trusted, or headless sessions ignore the allow rules: in ~/.claude.json, set projects["/Users/<you>/.buzz"].hasTrustDialogAccepted: true.
3. Restart the app.

Agents work again, and this keeps working regardless of which permission mode the harness defaults to — we run the same pattern on our headless server harnesses (buzz-acp → claude-agent-acp under systemd) where dontAsk + allowlist has been stable in production. Arguably a safer default posture than restoring bypassPermissions, since the old behaviour gave desktop agents unrestricted execution.

Gotchas we hit getting this working: Bash rules need the colon form (Bash(git:*), not Bash(git *)), and without the trust flag Claude Code logs "Ignoring N permissions.allow entries ... workspace has not been trusted" to stderr, which the harness swallows.

[skillz-xx]

Same-machine confirmation on macOS with Buzz Desktop 0.5.7, using two managed runtimes:

1. Managed Claude rejected two owner-requested review attempts under the unattended permission surface, including one explicitly read-only request. Desktop showed no approval UI.
2. The same machine had a separate managed Codex outbound-network regression. After that Codex path was repaired, a native buzz messages send returned accepted: true.
3. Managed Claude remained blocked.

That sequence rules out the relay, channel, signing identity, and bundled CLI as the cause of the Claude failure. It confirms that the dontAsk permission path can independently make an agent receive work, appear online, consume a full turn, and then fail at the only publication path.

Operator impact was severe: we lost almost a working day because the visible symptoms looked like relay/auth/delivery failures while inbound messages and agent execution remained healthy. The failure only became clear when tracing the denied tool/publish path.

#5262 / #5290 are the matching trackers and #5263 is the proposed fix. I recommend an end-to-end release gate with the current Claude Code version and a fresh, untrusted nest: buzz --help must execute and a signed buzz messages send must return accepted: true, without a manual trust dialog.