Mesh mirror: a consent prompt raised while the peer link is re-forming after a restart is never delivered to that peer

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 bug report

John Lauer · 1mo ago ·closed by John Lauer

Seen 2026-09-14 02:32 to 02:55 UTC during a Hydrogen reinstall test on arav-rog (ab 2.1.120, embedded), with the human on AdomLapper (ab 2.1.118).

What happened:

Hydrogen was uninstalled on arav-rog. The embedded ab lost its relay (Hydrogen's local one) and left the cloud relay. Someone relaunched ab on arav-rog at 02:32 (new process, standalone).
At 02:35 a relay caller ran run_script on arav-rog. ab correctly refused with needs_approval and surfaced its own dialog on arav-rog.
Nothing reached AdomLapper. desktop_mesh_status on AdomLapper showed lastError: connect to "arav-rog" timed out after 4s (no direct path and the relay did not deliver; is the peer online and its mesh on?); on arav-rog every peer showed connected: false and outboundOk: 0. Trust on both sides was intact (peer-grant entries for each other's node ids).
About 20 minutes later the AdomLapper to arav-rog link re-formed on its own (connected: true, path: relay, sinceSec: 187). A request_shell_approval on arav-rog at that point was mirrored to AdomLapper within seconds and the human approved it there.

So the mirror works, but a prompt raised while a peer link is still re-forming after a restart is not delivered to that peer once the link is up. The human on the other box never learns there is a pending approval unless the caller re-surfaces it.

Asks:

Queue pending consent prompts per trusted peer and deliver them when the link comes up (and withdraw them when decided), so a restart on either side cannot swallow a prompt.
Make the dial after a restart faster: 20 minutes to re-link two boxes that both sit on the relay is long; arav-rog had registered with the relay at 02:32 but AdomLapper's dial still timed out at 02:35.
Related: #191 (decision history for a box that was away) covers the read side of the same gap.

Repro: with two mesh-linked boxes, restart ab on box A, immediately run a gated verb on A from the cloud, watch box B. Then wait for desktop_mesh_peers on B to show A connected and call request_shell_approval on A: the second prompt arrives, the first never did.

2 Replies

John Lauer · 1mo ago

Ack. 2.1.127 (building now) keeps every prompt this box is still asking about (by id, 15 min, retired on dismiss) and replays them (a) to a peer the moment a mesh link to it forms, dialled or accepted, and (b) over the hc relay when the relay leg (re)authenticates. The replayed body carries the nonce issued at raise time, so a decision from the replayed card resolves like the original; receivers dedupe by id. The slow re-dial (20 min) is not addressed by this; it needs its own look at the relay-mode dial path. Live proof (restart one box, raise a buttoned prompt on the other, watch the card arrive when the link forms) follows once a second box is on the build.

John Lauer · 1mo ago

Shipped in 2.1.127 (insiders). What ab does now: every prompt still open on a box is kept by id (15 min, retired on dismiss or on a class-wide grant) and replayed (a) to a peer the moment a mesh link to it forms, on both the dialling and the accepting side, and (b) over the hc relay when that leg re-authenticates. The replayed body is the original one, nonce included, so a decision from the replayed card resolves exactly like the original; receivers dedupe by id. Measured today: arav-rog reported winvm connected:false, a buttoned prompt (id 64611e5a...) was raised on arav-rog, the link formed seconds later, and winvm's log shows the prompt arriving via relay at 16:03:27.080 and via mesh at 16:03:27.116 / .118 / .498 (the mirror attempt plus the link-formed replays from each side, one card), then 'card from arav-rog dismissed here (Got it on AdomLapper)' when it was decided elsewhere. The slow re-dial itself (20 min in the report) is not changed by this; if it recurs, file the desktop_mesh_status lastError and I will take the dial path separately.

John Lauer closed this · 1mo ago