mesh_enabled=false is ignored: after a restart the mesh starts anyway and re-joins every same-account 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 on winvm (ab 2.1.170, embedded under Hydrogen 1.0.560), 2026-10-07.

Steps: set mesh_enabled to false (settings_set needs a click on the box, so it was written to C:\Users\azureuser.adom\config.json directly), force-stop Hydrogen and adom-bridge, start Hydrogen (which starts ab).

After the restart:

settings_get answers mesh_enabled: false, and config.json still says false (ab did not rewrite it).
desktop_mesh_status answers enabled: true, uptimeSec: 30, peerCount: 3, connected to the account's other machines (AdomLapper, arav-rog, ConfRoomROG), relayConnected: true.

Expected: with mesh_enabled false the mesh does not start, the box publishes nothing to the account directory, and it receives no mirrored cards from the other machines. The setting's own help says the mesh is off by default and joining binds a port.

Why it matters: we run Hydrogen setup-pitfall tests on test PCs signed in to John's account. A brand-new user is not in any mesh (off by default), but the test PCs keep receiving mirrored alerts from John's other machines (toasts like 'New important notification'), so tests cannot tell real first-run noise from mesh noise. John asked for the test PCs to leave the mesh; this bug makes that impossible.

Possibly related: 'settings_set of an unrelated key bounces the mesh' (existing issue).

1 Reply

John Lauer · 1mo ago

Fixed in 2.1.171 (insiders now).

Cause: since 2.1.61 the mesh has a mesh_mode (off / relay / direct), and mesh_enabled is derived from it. When config.json had both and they disagreed (mesh_mode: "relay" and a hand-written mesh_enabled: false), the mode won, so the mesh started. ab itself always writes the two consistently, so a mismatch means a person edited the file, and for a networked feature off now wins. One function decides this for both the boot-time mesh start and settings_get, so the two can no longer disagree.

Checked on arav-rog (2.1.171):

Wrote mesh_enabled: false into config.json by hand (leaving mesh_mode: "relay"), then restarted ab.
desktop_mesh_status → running: false, mode: off, peerCount: 0; settings_get → mesh_enabled: false, mesh_mode: off; verbs reached the box through the cloud relay.
Restored afterwards with settings_set {mesh_mode:"relay"} (mesh back, 3 peers).

For the test PCs, settings_set {"settings":{"mesh_mode":"off"}} is the supported switch (it needs that box's shell approval); the hand edit now works too. The Settings text Hydrogen renders for this switch said "Off by default", which has not been true since 2.1.61; it now describes what off does.

John Lauer closed this · 1mo ago