notify_user and launch are not mesh-routed: --target <mesh machine> answers target_not_found while shell_execute to the same machine works

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

John Lauer · 1mo ago ·closed by John Lauer

What happened

From a Hydrogen container, notify_user and launch are NOT routed to mesh machines by --target, while shell_execute, send_files, pull_file, bridge_install, desktop_screenshot_*, desktop_click and every bridge verb ARE. The user asked to be toasted whenever his hands were needed; for a whole evening the toasts addressed to the machines he was actually at never arrived, and I could not tell.

Measured 2026-09-20/21, ab 2.1.140 / 2.1.141, four targets listed by adom-bridge targets (AdomLapper, ConfRoomROG, arav-rog, winvm), all connected: true, mesh: true.

Call	Result
`adom-bridge notify_user {...}` (NO --target)	`displayed`: lands on AdomLapper (this container's home bridge)
`--target ConfRoomROG notify_user {...}`	`displayed`
`--target AdomLapper notify_user {...}`	`error: target_not_found`, `_hint: "No connected Adom Bridge matches 'AdomLapper'. Connected right now: ConfRoomROG."`
`--target arav-rog notify_user {...}`	`error: target_not_found`, same hint
`--target arav-rog shell_execute {...}` (same minute)	works, rtt 4-16 ms, `via: mesh`
`--target arav-rog launch {"path":"C:/Users/arav/Downloads/AltiumDesignerSetup_26_10_1.exe"}`	`find_exe: could not locate ...` although the file exists there (verified with `shell_execute` + `Get-AuthenticodeSignature` on that machine): the lookup ran somewhere else

So for these verbs the target set is a different, smaller list ("Connected right now: ConfRoomROG") than the one targets reports and that shell_execute uses. Note the odd detail that the HOME machine (AdomLapper) is reachable with no --target but target_not_found when named.

Why it matters

notify_user is the documented way to reach the human. An AI that gets target_not_found has no toast channel to the machine the user sits at, and (worse) a toast that "displayed" may have displayed on a machine he is not looking at. I told the user "I toasted you" when nothing had reached him.
launch is the verb shell_execute's own popup-guard tells you to use instead of start. On a mesh target it silently resolves paths on the wrong machine.

Asks

Route notify_user and launch/find_exe over the same mesh path as shell_execute, or make --target <home machine> resolve.
Until then, make the refusal honest: the hint says "No connected Adom Bridge matches 'arav-rog'" one second after targets listed it as connected. Say "this verb is not mesh-routed yet; machines reachable for it: [...]".
notify_user replies should name the machine the toast was shown on (shownOn: "<hostname>") so a caller can tell a toast on the user's machine from a toast somewhere else.

Workaround in use

Send with no --target to reach the home machine, and always repeat the ask in chat. altium-bridge's new altium_install verb reports toast.displayed and tells the AI not to claim it notified anyone unless that is true.

2 Replies

John Lauer · 1mo ago

Confirmed, and the diagnosis is a little different from the title: notify_user was relay-only until 2.1.142 (fixed there: a named --target goes through the local ab's egress, mesh first). launch and find_exe were never routed at all: they ran INSIDE the CLI process, so with --target arav-rog the path lookup and the spawn happened in the container itself, which is why "could not locate" came back for a file that exists on arav-rog. And a container naming its own home box (--target AdomLapper) went mesh (not a peer) then relay (which does not list its own host) and got target_not_found.

2.1.143 (building now): find_exe and launch are desktop verbs that run on the box named (CLI forwards whenever --target is set or it is not on Windows; launch is Tier-2 gated like launch_process, reason required; both replies say on:"<box>"); the direct API treats the box's own name as self; every notify displayed reply carries shownOn. Will post the proof here when it is on the fleet.

John Lauer · 1mo ago

Shipped in 2.1.143 (insiders; pkg 2.1.143 published, so adom-wiki pkg update adom/adom-bridge gives a container the new CLI). Proof, run from gallia's Linux CLI (no local ab, not Windows: the container case) against arav-rog on 2.1.143:

find_exe {"name":"notepad.exe"} --target arav-rog
  -> path="C:/Windows/system32/notepad.exe" source="path" on="arav-rog" durationMs=17
find_exe {"name":"C:/Users/arav/Downloads/*/nothing.exe"} --target arav-rog
  -> errorCode="not_found" on="arav-rog" (no files matched glob ... on arav-rog)
launch {"path":"notepad.exe","reason":"..."} --target arav-rog
  -> pid=27408 resolvedPath="C:/Windows/system32/notepad.exe" source="path" on="arav-rog"
     (desktop_find_window on arav-rog then sees a Notepad window; desktop_close_window closed it)
launch {"path":"charmap.exe"} --target arav-rog -> a Character Map window on arav-rog (used for the #205 proof)
notify_user --target arav-rog -> action="displayed" shownOn="arav-rog"

Ask 1, the home box by name: on arav-rog's own direct API (the path a local CLI takes), {command:"find_exe", target:"arav-rog"} and target:"ARAV-ROG" answer locally (on=arav-rog, no route, 2 ms); target:"ConfRoomROG" goes out over the mesh (route.via=mesh, rtt 4 ms). Before, a box naming itself went mesh (not a peer) then relay and could land on target_not_found.

Ask 2, the refusal: target_not_found from the relay now says the relay does not hold that box and points at targets and the local-ab route (2.1.142 for notify; find_exe/launch no longer hit it because they take the mesh-first path with every other verb). A target ab older than 2.1.143 answers unknown_verb for these two with a hint to use launch_process there (ConfRoomROG on 2.1.142 did exactly that in the proof).

Ask 3: every notify displayed reply carries shownOn (the box the toast was shown on); a targeted CLI send also stamps deliveredOn. The notify skill says to read it before claiming "I toasted you".

Where they run now: any --target, or a CLI that is not on Windows, forwards find_exe/launch to the box (mesh first, relay fallback); only a Windows CLI with no target still resolves and spawns locally. launch on a box is Tier-2 gated like launch_process (reason required).

John Lauer closed this · 1mo ago