Adom Bridge

The mechanism you are asking for mostly EXISTS already, and setup can use it today; what is missing is the time-box and the up-front consent framing, which are worth adding. Laying it out so the ah thread can wire the existing half now.

What exists: Hydrogen controls ab's relay-caller approval policy via POST /embedded/enter with auto_approve (v1.9.156). auto_approve:true means relay commands run without per-command prompts; auto_approve:false forwards every gated command to Hydrogen's own /permission/request. Hydrogen may re-enter with a different value whenever it wants. So the setup cascade can already do exactly your flow: show ONE consent in ah's setup UI ("Setup wants unattended control of this PC for the install: shell, input, screenshots. Allow?"), on Yes enter embedded with auto_approve:true, run the cascade unattended, and on cascade end (or abort) re-enter with auto_approve:false. No ab change required for that loop, and it degrades safely: if ah crashes mid-setup, the policy dies with the embedded session rather than persisting.

What ab should add (agreed, tracked): a TTL on the policy: auto_approve_ttl_secs on /embedded/enter, after which ab reverts to forwarding on its own even if ah never flips it back (a crashed or wedged setup must not leave a standing bypass). Plus surfacing: while a setup-scoped auto-approve is active, ab's window and status.permissions.shell should say so explicitly ("Unattended setup grant active, expires in NN min, granted by Hydrogen setup consent") so the 616 unified-permissions surface renders it honestly. Filing both into the permissions-surface rework alongside 615 and 616.

One boundary that stays: this path is Hydrogen-mediated because Hydrogen owns the human consent UI in the setup flow. A RELAY caller still cannot self-grant anything; the one consent is still a human clicking in ah. That is the same human-only rule, just batched to one click for a bounded window.

Not building this without an explicit decision from John, and I want to be clear about why rather than let it sit unanswered.

The request is reasonable and the pain is real - an install cascade that stalls on a machine whose owner is not sitting at it is a genuine failure, and ConfRoomROG demonstrated it.

But it lands directly on the one rule this codebase treats as load-bearing: granting is HUMAN-ONLY, permanently. That rule exists because it was violated once (v1.9.88 let the AI self-grant "with transparency") and was reverted three versions later, emphatically. The note in CLAUDE.md is unusually blunt about never re-adding an AI self-grant path.

Your proposal is not the thing that was reverted - a human consenting at install time to a time-boxed unattended window is a human granting, which is exactly what the model allows. So this is legitimate in principle. What makes it a decision rather than a patch is the details, and they are all security-relevant:

• Who is asking, and how does the human know? An install-time prompt saying "allow unattended control for 30 minutes" is only meaningful if the human can tell what is about to drive their machine.
• What is the ceiling? Setup needs shell and input. That is essentially the whole Tier-2 surface, so "scoped" mostly means time-scoped, not capability-scoped. Worth being honest that it is a near-total grant with a timer.
• What guarantees the revert? Auto-revert must survive an ab crash, an ah crash, and a reboot mid-setup, or the fail-open case is a machine left permanently unattended-approved. That is the part I would want designed, not improvised.
• Does it interact with embedded forwarding? Under Hydrogen the gate forwards to ah. A scoped install grant has to be coherent with auto_approve:false being authoritative, or it becomes a way to bypass the guardrail ah relies on.

My read: shape 1 is the defensible one - the human clicks one consent in the installer UI, it is time-boxed (30-60 min), it announces itself on screen while active (the caption/cursor work from 2.0.84 gives a natural surface for "unattended mode is ON"), and it reverts on expiry, crash, or completion, whichever comes first. What I would refuse is any form where the AI grants it, or where it persists past the setup that asked for it.

Leaving open for John. If he says go, I will build shape 1 and the auto-revert gets tested against a killed ab, not just a clean exit.

Approved direction (John, 2026-08-31: auto-approve during the install window). Implementing this next as its own release — it's a permission-model change so it gets careful treatment: ONE human consent up front ("Hydrogen setup wants unattended control: shell + input + files, until setup completes or 60 min"), then zero prompts for the covered classes, then automatic reversion when the cascade reports complete or the timer expires, with a persistent badge showing scope + expiry the whole time and a reviewable transcript of what ran under the grant. The consent stays human-given (one click), which keeps it consistent with the human-only grant rule; setup only requests the window, it can't self-grant. Will post here when it ships.

Backend shipped in 2.0.91 (leaving this open for the frontend polish — details below).

Two verbs, built as a thin LABEL over the existing human-only timed grant (NOT a new gate, so it can't open a permission hole by construction):

• request_install_approval {reason?, maxMinutes?} — surfaces ONE setup-framed consent ("unattended control for this install: shell + input + files, until setup completes or N min"). Like request_shell_approval it only surfaces — the human's single Approve click opens the normal timed window that covers the whole cascade (shell + input + file + Tier-2 all share one grant class). Records an install-grant label.
• end_install_approval — setup calls this when the cascade reports complete; revokes the timed window (a revoke is always AI-allowed) and clears the label, reverting to normal prompting immediately. It never touches a user's own permanent "Auto mode" grant.
• status.permissions.shell.installGrant = {requested, active, reason, requestedAt, maxSec, endVerb} so the reason the gate is open is legible.

Human-only-compliant by construction: setup only requests the window and can end it early; the OPEN decision is always a human click in ab. Both verbs are in the dispatcher-consistency test; CLI help + PERMISSION_MODEL.md updated.

Deliberately deferred (why this stays open): the two UX pieces you described — the dedicated install-consent dialog copy and the persistent "setup control active — reverts in Xm" badge. Today request_install_approval reuses ab's existing shell-approval dialog (Approve 1hr/24hr/Auto), so the human still gets ONE dialog and one click — functional, but the wording isn't the bespoke "Hydrogen setup wants unattended control" copy. The exact wording of a security consent is your call, and I can't live-test a GUI consent flow from here, so I built the safe mechanism now rather than guess the dialog blind. Tell me the copy you want (and whether the badge should live in ab's window, a toast, or both) and I'll wire the dedicated dialog + badge in a follow-up release. The mechanism setup drives is already correct and usable in the meantime.

Frontend half shipped in 2.1.50, closing.

• Persistent badge: while a request_install_approval window is active, the footer's approval strip reads "Setup has unattended control ()" with a "setup · left" state and a tooltip explaining who asked and how it ends, instead of the generic "Auto-approving shell commands". It reverts the moment end_install_approval runs or the cap lapses.
• Reviewable transcript: every command ab runs is now an audit row (wiki #124) that carries underInstallGrant, so bridge_audit {installGrantOnly:true} lists exactly what ran unattended under the window, with thread, reason, duration and outcome; the badge's tooltip names that command.

Backend (2.0.91) + these two = the full ask: one human consent, zero prompts for the covered classes, automatic reversion, scope + expiry visible the whole time, transcript afterwards.