targets says connected:false for mesh boxes that answer verbs fine, so AIs tell users their machines are offline (container CLI; #179 again)

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

John Lauer · 29d ago ·closed by John Lauer

What happened

An AI in a Hydrogen container was asked to film a run on one of the user's other Windows boxes. It ran adom-bridge targets (container CLI, 2.1.174) and got:

arav-rog     connected:false  via:relay
ConfRoomROG  connected:false  via:relay
AdomLapper   connected:true   (primary)
winvm        connected:false

The _hint on that reply says "A request that does not name a machine means THEIR machine: use --target AdomLapper". So the AI told the user that both boxes were offline and asked a human to wake them.

Both boxes were up the whole time. The same CLI, one second later:

adom-bridge --target arav-rog --ai-thread "..." status
-> route: {"peer":"arav-rog","via":"mesh","rttMs":211}
adom-bridge --target ConfRoomROG --ai-thread "..." process_list
-> full process list over the mesh

connected only reflects the container's own command-relay client list. Same-account mesh peers that are fully reachable show as false.

This is #179 again, on the Linux/container CLI instead of the Windows one.

What every Adom user's AI needs

targets should report reachability, not relay attachment. For each directory peer, add reachable (true/false/unknown) plus route (relay | mesh-direct | mesh-relay). If a probe costs too much, mark mesh peers reachable: "mesh" and never print a bare connected:false for them. Rename the existing field to relayConnected if it has to stay.
targets _hint should say the other boxes are usable too. Today it only says to default to the primary. Add something like: "Every listed box is addressable with --target , over the cloud relay or the mesh. connected:false on the relay does not mean offline: try one cheap verb such as --target <name> --ai-thread <t> process_list before telling the user a machine is down."
Make ping --target <name> actually reach the target. It currently answers pong from the local endpoint (127.0.0.1:24680) whatever target is named, so an AI cannot use it as a liveness check. It should route like any other verb and return route.via, or refuse --target with a hint.
Skill text in adom-bridge, adom-bridge-discovery and adom-bridge-multi-machine. Add a short "Using the user's other machines" section near the top:
- The user's boxes (laptop, office PC, test rigs) are all on the mesh and addressable by name.
- targets lists them. Check reachability with a real verb.
- Before taking over a screen, look first: desktop_list_windows, desktop_get_foreground, desktop_screenshot_screen. Another AI thread or a person may be using the box, e.g. a Fusion "do not click or type" banner from another thread.
- Pick a free box rather than asking a human to wake one.
Today this knowledge is spread across the mesh skill's architecture notes, and nothing an AI reads at decision time says it.

Repro

Container with adom-bridge 2.1.174, any account with 2+ mesh boxes whose ab is attached to a different relay (or none): run adom-bridge targets, then run --target <peer> --ai-thread x process_list '{"reason":"repro"}'. Expected: both calls agree on whether the box can be used.

2 Replies

John Lauer · 29d ago

Same session, a second gap: pull_file from the container CLI never uses the mesh, so a recording made on a mesh-only box can't be brought back.

--target ConfRoomROG desktop_record_start, desktop_record_stop, read_file and run_script all work over the mesh (route.via: "mesh").
--target ConfRoomROG pull_file {"filePaths":["C:/Users/john/AppData/Local/Temp/adom-bridge-recordings/desktop-m0-20261012-211917.mp4"]} -> target_not_found, with the hint "Connected now: AdomLapper". The help text says "with --target and a mesh peer it comes over the mesh".
read_file has no offset/length, so chunking a 2.2 GB MP4 through it isn't possible either.
Related: ab's recordings janitor prunes oldest-first above 3 GB. A 46-minute 4K take is 2.2 GB, so on a multi-hour shoot take 1 is deleted while take 2 is still recording. I had to run_script a Move-Item after each take to save it.

What an AI needs:

pull_file routed over the mesh like every other verb, or read_file {offset, length} as a fallback.
A way to keep a take out of the janitor: desktop_record_stop {keep:true} or saveDir on desktop_record_start.
One line in the recording skill about both.

John Lauer · 26d ago

Fixed in 2.1.175 (insiders). This covers both the original report and your follow-up.

targets reports reachability, not relay attachment. Each row now carries:

reachable: true means a live link now; "mesh" means the mesh dials it on demand, which is normal when idle; false means no route.
route: relay, mesh-direct, mesh-relay or mesh.
relayConnected and meshLinkLive as the raw facts.

connected now means "usable", so a mesh box is never a bare connected:false. The _hint says every listed box is usable, tells you to check one with ping --target before calling it down, and to look before taking over a screen. Live just now from AdomLapper:

arav-rog and ConfRoomROG: reachable:true, route:mesh-relay
winvm: reachable:"mesh" (idle, dials on demand)

ping --target X reaches X. It used to answer from 127.0.0.1 whatever you named. Now --target arav-rog ping answers transport:peer, version:2.1.175, route:{peer:arav-rog, via:mesh}. It currently borrows the status verb, which is slow (about 14 s); a lighter probe comes next release.

pull_file:

It waits up to timeoutSeconds, default 3600. It used to be a fixed 600 s, which is what a 2.2 GB take over the mesh relay ran into.
When the mesh route fails and the relay doesn't hold the box, the reply now carries meshError (the real reason) next to target_not_found, so it no longer reads as "offline".
read_file {path, offset, length} reads byte ranges (up to 1.5 MB per call, with nextOffset/eof) as a fallback.

Keeping takes: keep:true on desktop_record_start or desktop_record_stop writes a <file>.keep marker, and the recordings cleanup skips that file. The reply says kept:true.

Skills: adom-bridge-multi-machine has a new "Using the user's other machines" section, and the recording skill covers keep and big pulls. Both ship in the 2.1.175 package.

John Lauer closed this · 26d ago