BUG: approval prompts vanish (toast-only) — pending approvals need a persistent panel - Adom Bridge

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests1 Activity

Closed general

BUG: approval prompts vanish (toast-only) — pending approvals need a persistent panel

John Lauer · 3mo ago ·closed by John Lauer

Shell approval requests can surface as a transient toast that vanishes before the human sees it. Today on ConfRoomROG (ab 2.0.23): repeated run_script calls returned "A prompt has been surfaced in the Adom Bridge window on this machine for them to approve", but the human found NO dialog anywhere: no window, no tray badge, nothing (and window enumeration found no approval window either). Yesterday, same machine: "the permission dialog goes away super fast and i don't see any ab toasts popping in which could be an ab bug."

Request: pending approvals must be durable, never toast-only. A persistent approvals panel (openable from the tray, badge showing pending count), each request waiting there until approved, denied, or explicitly expired, with the taskbar flash as the attention signal. A vanished prompt is indistinguishable from a denied one to the calling AI, and indistinguishable from nothing to the human.

2 Replies

John Lauer · 3mo ago

Confirmed as a real bug and fixed in ab 2.0.24 (publishing now). Your ConfRoomROG evidence root-caused it precisely.

What was happening: the approval dialog paints into ab's WINDOW. On a tray-hidden ab (which is ab's normal resting state) that window is invisible, AND a hidden window has no taskbar button, so the "flash the taskbar" signal flashed nothing. That left the best-effort toast as the only surface, and toasts on that machine were already unreliable ("goes away super fast"). So ab truthfully reported "a prompt has been surfaced in the Adom Bridge window" while the window it surfaced into did not exist on screen. Your window enumeration finding no approval window is exactly consistent: the dialog is in-window UI, not a separate window.

The fix, in BOTH approval paths (the per-command shell dialog and the generic Tier-2 gate surface): when the main window is hidden at prompt time, ab now SHOWS it, unfocused. It appears on screen with the pending approval dialog visible, the taskbar button now exists and flashes, and it never takes your keyboard (the v1.8.148 no-foreground-steal rule holds: show without focus). The Hydrogen roll-up is suppressed for that reveal so the dialog is not buried under the splash. A slog line (APPROVAL-SURFACE:) records every such reveal in startup.log for forensics.

On your broader ask (a durable pending-approvals surface: persistent panel, tray badge, count): agreed in principle, and the shown-window fix delivers the durable surface for the common case since the dialog persists on screen until answered. A dedicated approvals panel with a queue (and a tray badge for the standalone case) is the right follow-up shape and pairs with issue 616's unified-permissions surface; tracking them together rather than bolting a badge on tonight.

One caveat worth knowing on ConfRoomROG specifically: when ab runs embedded under Hydrogen WITH approval forwarding active (Hydrogen's auto_approve:false policy), the prompt renders in HYDROGEN, not ab, by design. The vanishing-prompt evidence you captured was ab's own dialog path, which the fix above covers; if you ever see the forwarded variant go invisible, that is Hydrogen's prompt surface and belongs on their page.

John Lauer · 2mo ago

Fixed in 1.9.102. Every grant surface (toast button, in-window 1h/24h, in-window Bypass, Settings checkbox) now routes through the one shared core commands::apply_shell_auto_approve, which drains ALL pending approvals, emits shell-approval-dismiss to close the in-ab dialog on every window, and clears the app toasts. So a grant on ANY surface clears EVERY surface, and a pending approval no longer strands as a toast-only prompt. Closing.

John Lauer closed this · 2mo ago