Local Claude Code agents cannot execute any tool: permission rules are never consulted

[natebitsats]

Local Claude Code agents cannot execute any tool: permission rules are never consulted

Summary

Local agents using the claude-agent-acp runtime cannot execute a single Bash command. Project-scoped Claude Code permission rules (<cwd>/.claude/settings.json) are never consulted, so there is no supported configuration in which a local agent can run a tool.

Because posting to a channel requires buzz messages send (a CLI call), the practical effect is that local Claude Code agents cannot participate in channels at all. They receive mentions, run a turn, and their reply reaches only the local terminal/activity view.

Environment

Buzz	0.5.7 (Buzz_0.5.7_aarch64.dmg)
Platform	macOS 15 (Darwin 24.1.0), arm64
Runtime	claude-agent-acp 0.66.0
Node	v24.18.0 (bundled)
Agent cwd	~/.buzz (confirmed via lsof and the agent's own Read tool)

Reproduction

1. Create a local agent using the Claude Code harness.
2. Create ~/.buzz/.claude/settings.json:

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

3. Start the agent and @-mention it, asking it to run
   buzz messages get --channel <uuid> --limit 1
4. The command is denied.

Observed

With permission_mode=dontAsk (the default):

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

With BUZZ_ACP_PERMISSION_MODE=default:

User refused permission to run tool

Across every agent transcript in ~/.claude/projects/-Users-natebragg--buzz:
17 Bash tool calls, 17 denied, 0 allowed. Includes bare, undecorated commands
that match an allow rule exactly — so this is not a compound-command or
prefix-matching artifact.

Expected

A command matching a permissions.allow rule should execute without a
permission request, in either mode.

Analysis

• dist/acp-agent.js defaults to settingSources: ["user", "project", "local"],
  and the agent's cwd is ~/.buzz, so ~/.buzz/.claude/settings.json should be
  loaded as project settings.
• buzz-acp passes no settingSources, allowedTools, or canUseTool override
  that I can find in the binary.
• No managed-settings policy exists on the machine; user-level settings contain
  no permissions block; no hooks, no settings.local.json.
• In default mode the tool call surfaces as an ACP session/request_permission,
  which buzz-acp auto-refuses — correct given there's no human prompt UI, but it
  means an allow-listed command should never have reached that point.

Net: the allow list is not being evaluated anywhere in the ACP path.

Impact

--permission-mode documents dontAsk as rejecting "operations that need
interactive approval because Buzz does not expose a human permission prompt."
That's reasonable — but with no way to pre-approve commands, it leaves agents
unable to do anything at all, including reply in a channel.

Suggested fix

Any one of:

1. Ensure the SDK query resolves project settings from the agent's cwd, so
   <cwd>/.claude/settings.json permissions.allow is honored.
2. Expose an allow-list in buzz-acp config (e.g. buzz-acp.toml) that maps to
   the SDK's allowedTools.
3. Auto-approve a documented set of buzz subcommands, since the agent already
   holds its own signing key and can only act as itself.

Note

The buzz-agent runtime does not have this problem, but it requires
BUZZ_AGENT_PROVIDER plus a BYO API key, so it isn't a drop-in substitute for
users on a Claude subscription.

[EveryOddPixel]

Root cause found, with a one-line workaround. Hit this independently on a different platform (macOS 12.7.6, x86_64, self-built 0.5.7), which suggests it is not arch- or OS-specific.

Claude Code silently ignores permissions.allow from a project directory that has never been trusted. ~/.buzz is created by Buzz itself and is never marked trusted, so every project-scoped rule there is dropped before matching ever happens. That is why the rules appear to be "never consulted" — they are discarded at load time, not failing to match.

Claude Code does say so, but the message goes to stderr where the agent log never surfaces it. Running the same configuration by hand from ~/.buzz makes it visible:

$ cd ~/.buzz
$ claude --print --permission-mode dontAsk --setting-sources user,project,local \
    "Run exactly this command and show me its raw output or error: buzz --help"

Ignoring 1 permissions.allow entry from .claude/settings.json: this workspace has
not been trusted. Run Claude Code interactively here once and accept the trust
dialog, or set projects["/Users/<you>/.buzz"].hasTrustDialogAccepted: true in
/Users/<you>/.claude.json.

Bash access was denied by permission settings ("don't ask mode"), so I can't run
`buzz --help` directly.

This also explains why no permission mode helps. It is not a dontAsk bug: the allow rule does not exist as far as the matcher is concerned, so dontAsk correctly denies, and default correctly asks (and the ACP client refuses, giving "User refused permission to run tool").

Workaround

Add the nest to the trusted-projects list in ~/.claude.json:

{
  "projects": {
    "/Users/<you>/.buzz": { "hasTrustDialogAccepted": true }
  }
}

Restart Buzz so agents create fresh sessions. In my case the same agent went from 16 denials across 5 sessions to sending on the first attempt:

CMD >> buzz messages send --channel <uuid> --reply-to <id> --content "..."
RES: {"accepted":true,"event_id":"2f70e8d4..."}

Rules in user settings (~/.claude/settings.json) are honored regardless of trust, so that is an alternative workaround if you would rather not touch .claude.json — at the cost of applying the rule globally rather than only inside the nest.

Why an agent can never resolve this itself

The remedy Claude Code suggests is "run Claude Code interactively here once and accept the trust dialog." Managed agents are non-interactive, so that dialog can never be shown, and the trust flag can never be set from inside the agent. The failure is also invisible from the agent's side: it sees only a generic permission denial with no indication that a rule was dropped. In my case the agent reported, repeatedly and confidently, that "buzz commands are being auto-denied by this session's permission settings" and asked a human to fix the permission config — which was a dead end, since the config was already correct.

Suggested fix

Since Buzz creates ~/.buzz, it is in a position to vouch for it: have nest init set projects[<nest>].hasTrustDialogAccepted = true in ~/.claude.json when it creates the directory, alongside AGENTS.md/SKILL.md.

Surfacing Claude Code's stderr in the agent log would also have turned this from a multi-hour diagnosis into a single readable line, and would help with the next failure of this shape.