fix(desktop): seed nest Claude settings with buzz CLI allowlist

[thomaspblock]

Fixes #5262. Related: #5260 (same root cause, independently reported twice today).

Problem

Since #4609 the ACP harness rejects every session/request_permission (fail closed), and desktop managed sessions run in dontAsk mode with no in-app approval prompt. Claude Code raises a permission request for any Bash pattern not pre-authorized in its settings — so managed Claude agents lost all access to the bundled buzz CLI. They cannot read channels or send replies while appearing online. Reported by an X user and reproduced independently on Linux self-hosted, Windows/ECS, and macOS/hosted (#5260).

Fix

Claude Code evaluates permissions.allow rules before the permission mode, so a project-level allow rule survives dontAsk (confirmed as a manual workaround by a reporter in #5260). This PR seeds <nest>/.claude/settings.json with Bash(buzz) and Bash(buzz:*) during ensure_nest_at:

• Managed sessions start with the nest root as cwd, and the claude-agent-acp adapter passes settingSources: ["user", "project", "local"], so the project rules apply to every managed Claude agent.
• The user's own ~/.claude/settings.json is never touched.
• Merge is conservative: existing settings preserved, only missing rules appended, unparseable or unexpectedly-shaped files left untouched, atomic write (temp file + persist, matching refresh_skill_md_if_stale), idempotent across launches.

This deliberately does not reopen the blanket auto-approval #4609 removed — only the platform's own CLI is pre-authorized, agent-side, which #4609 explicitly scopes as outside the harness guarantee ("An agent that pre-authorizes tools in its own configuration … is outside this harness"). The broader fix (harness permission policy + desktop approval cards) is in flight as #5106; this unblocks agents until it lands.

Known limitation

Allow rules match single commands only: buzz feed get runs, but buzz ... | head or buzz ...; echo $? still raises a request and is rejected under dontAsk. Agents that chain the CLI with shell operators remain affected until #5106.

Testing

• cargo test --lib in desktop/src-tauri at 724fed49d: 2280 passed, 0 failed (2275 base + 5 new claude_settings tests: create-when-absent, merge-preserving-other-keys, idempotence, invalid-JSON untouched, unexpected-shape untouched)
• cargo clippy --lib: no warnings
• cargo fmt -- --check: clean

[colbymaloy]

yea need this one in asap boys

[apatrida]

yea need this one in asap boys

Yeah, spent about 90 minutes on this one today until narrowed it down to the conflicting startup and config. Anyways, reported, and being handled it appears.

[LucasMoskun]

I tested this patch strategy against Claude Code 2.1.220 on Buzz Desktop 0.5.6, macOS, with a locally managed agent connected to a self-hosted relay. The proposed <nest>/.claude/settings.json location did not unblock buzz after a full agent restart.

The fresh headless Claude process emitted:

Ignoring 2 permissions.allow entries from .claude/settings.json: this workspace has not been trusted.

This matches the current Claude Code workspace-trust behavior: project permissions.allow rules grant capability and are ignored until the workspace trust dialog is accepted. A Buzz ACP-managed session cannot present that dialog. See https://code.claude.com/docs/en/permissions#project-allow-rules-and-workspace-trust

I then moved the exact same rules:

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

to <nest>/.claude/settings.local.json. Under the same cwd, --permission-mode dontAsk, and --setting-sources user,project,local, a fresh Claude invocation executed buzz --help and returned permission_denials: [].

Recommendation: seed and conservatively merge <nest>/.claude/settings.local.json instead, and add an integration check using a current Claude Code version with an untrusted fresh nest. Programmatically marking the nest trusted in the user-wide trust registry seems less isolated than using the local settings source.

I posted the full reproduction on #5262 as well.