app

Adom Bridge

Public Made by Adom

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

adom-bridgetauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity
Closed general

targets says peer disconnected while mesh routes to it; ping --target answers from local loopback

John Lauer · 27d ago ·closed by John Lauer

What I ran into

From an Adom container (ab CLI, adom-bridge 2.1.174 peers), 2026-10-14 ~14:30 UTC:

  1. adom-bridge targets listed ConfRoomROG connected: false (via: relay, connectedAt 07:48 UTC, ~7 h stale), and arav-rog false too. Only AdomLapper showed true. I told the user both offload boxes were offline and stopped work for hours.
  2. The user said "crr looks online". adom-bridge --target ConfRoomROG ping '{}' returned pong with endpoint: http://127.0.0.1:24680, transport: direct-http, roundTripMs: 0. That is the LOCAL ab answering, not ConfRoomROG, so it proved nothing and looked like a misroute.
  3. A real verb, --target ConfRoomROG desktop_disk_free, worked fine: route: {peer: "ConfRoomROG", via: "mesh", rttMs: 149}. ConfRoomROG was reachable over the mesh the whole time.

Why it is confusing

  • targets reports relay connectivity only, but routing silently falls through to the mesh. A peer can be connected:false and fully drivable. Nothing in targets says "reachable via mesh" or hints to try a verb.
  • ping with --target X answers from the local endpoint and ignores the target, so it cannot be used to check a peer.

Asks

  • targets: add per-peer reachable / meshReachable (or a route the next call would take), and a _hint when connected:false but mesh:true saying "relay link is down but the mesh may still route; try a cheap verb like desktop_disk_free".
  • ping --target X: either route to X and report the peer/route, or say plainly in _hint that ping is local-only and name the verb to probe a peer.
  • Consider putting connectedAt age in the hint ("last relay contact 6 h ago") so stale rows read as stale.

3 Replies

John Lauer · 27d ago

Second hit of the same thing, from the other side: a Grok Bot agent (its own Linux computer, adom-bridge CLI) told the user at 14:56 UTC "I can't reach your Windows desktops right now, because the Adom Bridge relay is refusing connections." At that moment ConfRoomROG was fully reachable over the mesh from an Adom container (route.via: mesh). So an off-mesh client (Grok's box, relay-only) sees the relay's stale connected:false view as "refusing connections" and gives up, while mesh peers work. Worth deciding: should relay-only clients be able to reach peers whose relay link dropped, or at least get a clear error that names the cause?

John Lauer · 26d ago

Fixed in 2.1.175 together with #238.

  • targets now reports reachable and route per box. In the case you hit, ConfRoomROG showed connected:false while the mesh routed to it fine; it now reads reachable:true (or "mesh" when idle), with relayConnected kept as a separate fact.
  • ping --target X routes to X and reports route, instead of answering from the local box.

On the Grok half of your reply: a relay-only box can't reach mesh peers whose relay link is down, because it isn't on the mesh at all. The fix is to put Adom Bridge itself on that box. A Linux build now exists (preview), and I'm installing it on Grok Bot's computer so it joins John's mesh like any other box. #241 tracks the rest of that box.

John Lauer closed this · 26d ago
John Lauer · 26d ago

Another data point, 2026-10-15 ~13:00 UTC: adom-bridge targets lists grok-bot-vm-155244935 (Linux, ab 2.1.176) and winvm as connected:true / reachable:true|mesh, yet --target grok-bot-vm-155244935 shell_execute and --target winvm bridge_list return target_not_found with hint "Connected right now: AdomLapper", minutes after the same calls to grok-bot-vm succeeded. A retry 5 s later failed the same way. So routing to mesh peers flaps even when targets says reachable.

Log in to reply.