fix(acp): let an unattended bridge answer session/request_permission

[mattbalza]

Why

The 2026-08-07 08:46 UTC deploy of bfa150be5 (the 136-commit upstream ingest) took all four server agents mute. Upstream ad538bfb1 flipped session/request_permission from auto-approve to an unconditional reject_once and deleted PermissionMode::BypassPermissions.

That is the correct posture for an attended client. For our droplet bridges it is a silent outage:

• nobody is awake to answer the prompt, so every tool call an adapter asks about is refused;
• @codex publishes its reply through mcp__buzz__buzz_send_message, so a refused tool call is not an error — it is an invisible turn. The journal logged matched turn starting / turn complete pairs, the workers burned CPU, and the channels stayed silent.

We are keeping upstream's hardening. BypassPermissions is not coming back.

What

Adds the opt-in upstream is already writing: BUZZ_ACP_PERMISSION_POLICY from block/buzz PR block#4938 (branch duncan/permission-policy), using upstream's exact value names (allow | ask | reject) and its reject default. When an ingest carries that PR, this patch is a deletion, not a merge reconciliation — both hunks carry a header comment saying so.

allow selects the request's unique allow_once option and nothing else:

request shape	outcome
exactly one allow_once with a string optionId	selected
no allow_once	denied (reject_once)
several allow_once	denied — we would be choosing between distinct grants
allow_once with missing/non-string optionId	denied
allow_always present	never selected
policy reject (default) or ask	byte-for-byte today's output

ask exists so an upstream-shaped config value can never fail clap parsing and take a bridge down; with no prompt surface it denies like reject.

The policy is published once by Config::from_args into a process-wide fail-closed AtomicBool, because handle_permission_request answers on the agent's I/O task and never sees a Config. The decision itself is a pure function (permission_response(allow, id, options)), so the tests never touch the global.

The boundary

Our permission boundary is the OS sandbox — bubblewrap, one UID per identity, [permissions.*] in each config.toml, network.enabled = false, and the broker socket — not an ACP prompt no human is there to answer. That sentence is in the patch comment.

Logging blind spot

Both permission log lines target acp::permission, and RUST_LOG=buzz_acp=info filters targets by prefix — so neither ever appeared, which is why this shipped invisibly. The request line goes debug! → info! and the denial goes info! → warn!. The matching acp::permission=info directive lands on the four bridge units in the ERP repo, asserted by provision-buzz-isolation.sh verify.

Test plan

cargo test -p buzz-acp — 722 passed, 0 failed, including:

• allow_policy_selects_the_unique_allow_once
• allow_policy_denies_when_allow_once_is_ambiguous
• allow_policy_with_no_options_is_cancelled
• allow_policy_denies_allow_once_without_string_option_id
• allow_policy_never_selects_allow_always
• reject_policy_is_identical_to_the_unconditional_denial (numeric id, string id, empty options)
• only_allow_flips_the_published_policy
• test_permission_policy_value_enum_is_lowercase, test_summary_includes_permission_policy, test_summary_permission_policy_default_is_reject, test_only_allow_policy_permits_selection

test_permission_mode_rejects_unattended_bypass is untouched and still passes. cargo clippy -p buzz-acp --all-targets is clean.

Prod round-trip (the check the 08:46 deploy skipped) runs at deploy: a human mentions @codex in a channel and gets a kind:9 reply, cross-checked against the rollout JSONL under /var/lib/buzz-acp-codex/codex/sessions/ where every mcp_tool_call_end must carry a result rather than {"Err":"user rejected MCP tool call"}.

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.