Urgent approval toasts need a one-time human Allow per box to pierce DND — unattended boxes can't self-serve - 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 Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

Urgent approval toasts need a one-time human Allow per box to pierce DND — unattended boxes can't self-serve

John Lauer · 2mo ago ·closed by John Lauer

Urgent approval toasts need a ONE-TIME human "Allow important notifications" per box — unattended boxes can't self-serve

Context: 2.0.48 made both approval toasts (shell + web-control) scenario="urgent" so they pierce Focus Assist / Do Not Disturb. Diagnosed live: with DND on, a normal-priority approval toast is delivered to the notification center but its BANNER is suppressed, so the user sees the in-window dialog and no toast.

The catch found while proving it on two boxes: scenario="urgent" does NOT silently break through DND. The FIRST urgent toast ab posts on a box triggers Windows' one-time prompt:

"Important Notification Request — Allow important notifications from Adom Bridge? You will get important notifications from Adom Bridge when do not disturb is on. To change this later, select this app in notification settings. [Allow] [Not Now]"

Until a human clicks Allow on that machine, the approval BANNER stays suppressed (the prompt shows instead). Proven live: AdomLapper had already been granted (its shell approval banner shows correctly), ConfRoomROG had not, so ConfRoomROG shows the "Allow important notifications" prompt in place of the approval banner.

The problem this creates: on an UNATTENDED box (e.g. ConfRoomROG, driven remotely), nobody can click Allow, and ab cannot grant it for the user (it is a Windows system prompt, and ab must never elevate/priority-register silently). So the urgent-toast DND-pierce is unavailable on exactly the headless/remote boxes where the toast matters most. The in-window dialog is still the reliable surface (it does not depend on notifications), so no gate is broken — but the "toast banner" experience is gated behind a per-box human click.

Options to consider:

Register ab in the Focus Assist / notifications priority list at INSTALL time (elevated NSIS context), so no per-box runtime click is needed. Needs research: whether the priority list is settable programmatically per-AUMID (HKCU notification settings) without the interactive "Allow important notifications" consent, and whether doing so is acceptable (it is a user-notification-preference write, not a security elevation).
Detect the un-granted state and surface it in ab's UI ("Approval banners are muted by Do Not Disturb — click here / open notification settings to allow"), turning the invisible one-time gate into a visible, actionable one.
Accept it and DOCUMENT it: the in-window dialog is the reliable surface; the toast banner requires a one-time Allow per box; on unattended boxes rely on the dialog + request_shell_approval + the relay verbs.
For the embedded (ah) case, let ah own the prompt (it already forwards approvals) so the priority grant is ah's one-time thing, not ab's.

Recommendation: (2) short-term (make the muted state visible + one-click fixable), (1) if the per-AUMID priority write turns out to be non-interactive and acceptable.

Related: the shell + web-control approval toasts were made urgent in 2.0.48; the in-window dialog remains the primary surface (v2.0.24 shows the hidden window for the dialog). This issue is specifically about the toast BANNER's per-box priority gate.

2 Replies

John Lauer · 2mo ago

Shipped in 2.0.65, taking your recommendation (2). Option (1) I researched properly and then rejected, which is the part worth your review.

Option 1: technically possible, and that is exactly why not

The grant is plain HKCU. Measured on AdomLapper, which had already been granted:

HKCU\Software\Microsoft\Windows\CurrentVersion\Notifications\Settings\inc.adom.bridge
    Enabled                   REG_DWORD 0x1
    ShowBanner                REG_DWORD 0x1
    AllowUrgentNotifications  REG_DWORD 0x1     <- the grant

No elevation, no UAC. ab could set it at install time or at launch, and nobody would ever see the prompt again.

So it is a judgment call, not a capability question, and the answer is no. Windows shows that prompt so a HUMAN decides whether an app may pierce their Do Not Disturb. An app that writes the flag for itself has silently granted itself the right to interrupt the user - which is the same thing we refused to let the AI do with shell approval, for the same reason. The AI may TRIGGER a human decision; it may never make one on the human's behalf. Writing AllowUrgentNotifications from ab would be that rule broken in a place nobody would notice.

I would rather say that plainly than quietly implement it because it turned out to be easy.

What shipped instead (option 2)

ab READS the state and never writes it, and the invisible one-time gate is now visible and actionable:

status.permissions.notifications -> {appId, urgentAllowed, bannersEnabled, reliableSurface, _hint}. It rides permissions_json(), which BOTH status builders already call, so the relay AND the direct API get it without the two-builder drift.
notification_settings_open (alias request_notification_permission) - the AI's lever, deliberately mirroring request_shell_approval: it opens Settings > System > Notifications and reports alreadyAllowed. It never grants.
A GUI banner that appears ONLY when notifications are ON but the pierce was never granted, with a Fix button. If the user turned banners off entirely, that is a deliberate choice and ab stays quiet. It reuses the existing update-banner CSS, so no new colors and no bare-button dark-mode regression.

Verified live on this box:

appId          : inc.adom.bridge
urgentAllowed  : true
bannersEnabled : true
reliableSurface: in-window dialog (request_shell_approval) - never depends on notifications

The unattended case, honestly

For an unattended box this does not conjure a banner out of nothing - nobody is there to click, and that is inherent. What it changes is that a remote AI can now see the muted state and stop waiting on a toast that will never render, which is the actual failure mode: the toast was not just absent, it was invisibly absent.

So option 3 remains the operational answer for those boxes, and the response _hint says so directly: use request_shell_approval (the in-window dialog does not depend on notifications at all) or the relay approval verbs. Your option 4 - ah owning the prompt in embedded mode - is still the cleanest end state there, since ah already forwards approvals; that belongs on ah's board and I have not filed it.

One caveat I would rather state than have you discover: I could not test the UNGRANTED path on this machine, because AdomLapper was granted long ago. The code treats a missing registry key as "not granted" (fresh-box state), and ConfRoomROG is the natural place to confirm the banner actually appears.

John Lauer · 2mo ago

Closing: shipped in 2.0.65 taking recommendation (2). Option (1) was researched and deliberately rejected, with the HKCU measurement recorded above so the next person does not re-explore it: the grant is writable, and that is precisely the reason not to write it. A notification permission the user did not grant is not a permission.

John Lauer closed this · 2mo ago