Repository navigation
Managed agents silently muted: Claude Code sessions spawn in deny-by-default (dont-ask) permission mode with no owner-facing way to configure it #5332
Description
Summary
After a Buzz Desktop restart on 2026-08-08, all managed Claude agents on this machine came up in Claude Code's "don't ask" permission mode: every tool call not matching the project allowlist is auto-denied with no prompt. Because buzz messages send runs through Bash, agents could not even post an error — from the human's side they simply went silent mid-conversation.
Timeline / correlation
- Agents had run for weeks with working tool access (model: opus[1m]).
- Owner switched most agents' model to
claude-fable-5[1m]and did a full app restart the same day. The muting appeared immediately after. - Hypothesis: the new runtime/model default is deny-by-default for headless sessions, and buzz-acp passes no permission configuration at spawn, so agents inherit whatever the runtime defaults to.
Evidence
managed-agents.jsonhas no permission-related field per agent (keys inspected: acp_command, agent_args, agent_command, ..., respond_to, runtime, model — nothing about permissions).agent_argsis[]for every agent, andglobal-agent-config.jsonhas no permission setting either — there is no owner-facing knob, UI or file, to set the Claude Code permission mode for a managed agent.- Recovery was only possible because the shared workspace's
.claude/settings.local.jsonallowlist is honored: addingBash(buzz *)and similar rules restored function live, with no restart needed. An agent cannot self-repair: the harness (correctly) refuses agent edits to its own settings file, so a human must hand-edit it.
Impact
Silent total outage of all managed agents; looks to the human like the agent is ignoring them. Related family of issues where agent runtime behavior is not what the owner expects: #3858 (workflow events lack auth tag) and the respond_to sync bug reported earlier.
Request
- Have buzz-acp pass an explicit, owner-visible permission mode (or generated allowlist) when spawning agent sessions, rather than inheriting runtime defaults.
- Surface send failures: if an agent turn ends with its message-send tool denied, show an error in Desktop instead of nothing.
- Document the interaction between managed agents and the workspace
.claude/settings.local.jsonallowlist.
Activity
wolfyy970 commentedon Aug 8, 2026
The immediate regression is fixed in #5325. It stops forcing
dontAsk, leaves the adapter in its default permission flow, and answers an offeredallow_oncerequest through the existing ACP harness. That restores the tool path without returning to blanketbypassPermissions.The current head is mergeable and the production wire regression is green. #5106 is the larger owner-facing Ask, Allow and Reject control; it still needs its runtime validation before merge. #5270 covers the separate failure where a directly addressed turn ends successfully without publishing a reply.
Brodin2001 commentedon Aug 27, 2026
Hey — I found your Buzz issue around managed Claude agents silently coming up in the wrong permission mode.
I'm working on a small external authorization layer for agents, partly because I'm interested in what happens when you have multiple agents with different policies rather than one interactive session.
Would you be open to trying it against one of your managed agents?
I'll help get it installed for free. I'm mainly looking for feedback from people actually running multiple agents — whether the approach makes permission management easier or just introduces another thing to maintain.