Adom Bridge
Public Made by Adomby 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
Toast/permission click while ab is in the tray: no record in the Activity Log (suspended webview drops it), and in embedded mode the click should reveal ah, not ab
John, 2026-09-09: two things wrong with what happens when you click an ab toast or permission prompt while ab is hidden in the tray.
1. The window comes forward with no record of what you clicked
The Activity Log is frontend-only: every emitter calls app.emit("activity-log", ...) and the webview appends a DOM row. Nothing is stored on the Rust side. A tray-hidden ab runs with a suspended webview (webview_lowmem.rs, TrySuspend), so every entry emitted while hidden is dropped: the toast you are about to click, the permission prompt that woke you, the command that caused it. Click the toast, ab comes forward, the log shows nothing about it.
Fix (2.1.80): a backend ring buffer (activity.rs, 500 entries, process lifetime). Every one of the ~80 emitters now goes through ActivityEmit::emit_activity, which records first and emits second; entries carry a monotonic seq. The frontend replays get_activity_backlog {sinceSeq} on boot, on becoming visible/focused, and on the activity-refresh nudge the click reveal sends; seq makes the replay idempotent. The default body-click URI now carries the toast's correlation id (adom-bridge://toast/open?id=...), the toast's own log line carries it as cmdId, and the reveal fires activity-focus {id} so the log scrolls to and flashes the line for the toast you clicked. The reveal itself writes a line ("revealed Adom Bridge" / "revealed Hydrogen") with the same cmdId, so it groups with the toast under the existing rail.
2. In embedded mode the click should reveal ah, not ab
dispatch_adom_uri's raise showed ab's window unconditionally. When ab runs under Hydrogen, every card ab raises is mirrored into ah (shell, web-consent, mesh-join, firewall all go through permission_mirror::request -> hd_bridge::mirror_permission_request) and ah is the app in charge; popping ab over it answered the click with the wrong app. The per-toast focus:{host:true} opt-in already existed, but nobody sets it and the cards don't use it.
Fix (2.1.80): when embedded::is_embedded_now() and Hydrogen has a window (hd_companion::hd_running_window), the reveal foregrounds Hydrogen and leaves ab where it is. No ah window right now (mid-relaunch) -> fall back to ab, so a click is never a dead end. Applies to the toast body, the shell-approval body and the web-consent body clicks; the decision buttons (approve/deny/notify-response) still never raise anything, per 1.9.195.
Not changed: what ah itself keeps as a record of a toast. ab's log now has it; whether ah wants its own history is hydrogen's call.