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

bridge_install says ✓ while bridge_registry rejects the bridge.json — bridge silently disappears; validate + surface the parse error

John Lauer · 2mo ago ·closed by John Lauer

bridge_install reports ✓ for a bridge.json the registry cannot parse — the bridge silently vanishes on its next reap

What happened (altium bridge, 2026-08-31): bridge.json shipped four verbs[] entries as {name, description} objects instead of strings. ab logged [bridge_registry] parse ...\bridges-cache\altium\bridge.json failed: invalid type: map, expected a string at line 84 column 4 — but only in %LOCALAPPDATA%\inc.adom.bridge\logs\Adom Bridge.log. Meanwhile:

  • the bridge kept running on its stale in-memory registration for hours (verbs routed fine, LEDs green);
  • bridge_kill reaped it → it could not re-register → bridge_list simply omitted it, altium_* became Unknown verb — no installed bridge claims this prefix;
  • bridge_install from the manifest returned ok, method in_place_merge, "✓ Installed 'altium'. Its capsule ALREADY shows in the GUI" — three times — while the registry never accepted it; refresh_bridges returned ok with no error; bridge_info/bridge_resume said "not in registry".

So the author's whole signal was "everything says ok, the bridge is gone", and the only truth was a WARN in a log the CLI never surfaces.

Asks:

  1. bridge_install (and refresh_bridges) must validate the manifest it just cached and fail loudly with the parse error (errorCode: manifest_invalid, the serde message, the line) instead of ✓.
  2. A registry parse failure should show up in bridge_list as a row with state: "invalid" + the reason, not as absence — absence is indistinguishable from "never installed".
  3. bridge_log_read (or a bridge_lifecycle verb) should expose ab's own lifecycle log entries for that bridge ([bridge_registry], [dynamic_bridge] reaped …), since server.out.log only exists once a process spawned.
  4. Nice-to-have: reject the manifest at publish time — adom-wiki release/pkg lint could validate bridge.json against the SDK schema; the SDK manifest skill should state plainly that verbs[] is string[].

Repro: put {"name":"x_ping","description":"…"} into any bridge's verbs[], bridge_kill it, then bridge_install — ✓ with no bridge.

1 Reply

John Lauer · 2mo ago

Fixed in 2.0.89 (the fix landed in 2.0.88; 2.0.89 is the current release).

install_from_manifest_url and the update path now parse the freshly-cached bridge.json as the strict Bridge schema before the cache swap. A manifest that parses as JSON but not as Bridge (the exact repro: verbs[] carrying {name,description} objects instead of string names) is refused up front with errorCode:"manifest_invalid" plus the offending line and column, so the install never lands a broken bridge that would silently vanish from bridge_list. A bridge already in that broken state now surfaces in bridge_list as a status:"invalid" row with invalidReason + invalidAt instead of pure absence. The SDK manifest doc now states plainly that verbs/verbPrefixes are arrays of strings, and the CLI help documents the new errorCode. Unit tests lock in the repro.

John Lauer closed this · 2mo ago

Log in to reply.