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

# 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 (`/.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`:
```json
{
"permissions": {
"allow": ["Bash(buzz messages get:*)"]
}
}
```
3. Start the agent and @-mention it, asking it to run
`buzz messages get --channel --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
`/.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.