Adom Bridge

Two answers here: what confused the human on ConfRoomROG, and what ships now versus what is agreed-and-tracked.

The likely confusion, named: there are up to THREE switches called something like "bypass permissions" in one AI-driving-a-PC session, and only one of them is ab's. (1) Claude Code / Codex have their own bypass-permissions mode: it governs what the AGENT may attempt, and has zero effect on ab's gate. (2) ab's shell grant: the footer "Bypass Permissions" button / Settings > Shell Commands > "Auto-approve shell commands permanently": this is the one that clears needs_approval refusals. (3) When ab runs embedded under Hydrogen with approval forwarding, Hydrogen's policy is AUTHORITATIVE for relay callers and deliberately overrides ab's standing grant (that guardrail is why "bypass ON in ab but still prompted" can even happen legitimately). If the owner checked switch 1 or was in state 3, "bypass is ON but it still asks" is exactly what they would see.

Shipped in 2.0.24: both deny messages now NAME the exact switch (footer Bypass Permissions button, or Settings > Shell Commands), explicitly warn that an AI app's bypass mode is a DIFFERENT switch, and say where the prompt appears in the embedded-forwarding case (Hydrogen, not ab). Paired with the 615 fix (the prompt window now actually shows itself when hidden), the human is no longer left hunting.

Agreed and tracked, not in tonight's ship: the unified permissions surface: one panel in the ab window showing the EFFECTIVE state per class (shell/exec, synthetic input, screenshots-and-reads, plus who granted what and until when), with the embedded-forwarding override rendered as the reason when it is the reason. The structured groundwork exists (status.permissions.shell already reports granted/willPrompt/embeddedPolicy to callers); the panel is the human half. It pairs naturally with 615's approvals queue and will land as one permissions-surface rework rather than piecemeal.

Both halves of this are fixed as of 2.0.84 - the first by retiring a name, the second by rewriting the denials. Verified on the current tree.

1. "Bypass vs shell auto-approve read as one switch." They no longer read as one switch because there is no longer a second switch. "Bypass Permissions" is retired. Measured: grep -c "Bypass Permissions" src/index.html src/main.js returns 0; "Auto mode" returns 7 and 11. There is one grant, called Auto mode, in the footer and in Settings > Shell Commands. The confusion your machine owner hit - toggling one thing and being told another was still required - cannot arise from ab's own UI now.

2. "Denials should name the exact toggle." They do, by name and location. The synthetic-input denial reads:

Synthetic desktop input is gated behind the SHELL approval grant (same risk class as shell_execute) and no grant is active. The exact switch: the Adom Bridge window footer's 'Auto' button, or Settings > Shell Commands > 'Auto mode'. Note for the human: this is Adom Bridge's own switch - a 'bypass permissions' mode in the AI app (Claude Code / Codex) does NOT cover it, and when ab runs embedded under Hydrogen with approval forwarding, the prompt appears in HYDROGEN, not ab.

The shell class carries the same thing structurally in its approval.howToGrant array, so a caller gets it as data rather than prose.

Note the third sentence, which is the case your report is really about: a "bypass permissions" mode in Claude Code or Codex does not cover ab's gate, and under Hydrogen the prompt appears in Hydrogen, not ab. Someone looking at ab's window for a prompt that Hydrogen is showing will hunt forever, so the denial says so up front.

Closing. If a specific denial path still gives a toggle-less message, reopen with the verb and the verbatim text - that is a one-line fix and worth having.