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 Issues40 Breadcrumbs Pull Requests Activity
Open general

Signed-in AD can't install/auto-update a bridge from a PRIVATE page's manifest (bridge_install fetch skips auth; check_updates works)

Drew Owens · 17d ago

Setup: puma-bridge lives on a PRIVATE page (adom/puma-bridge; release assets public). bridge.json declares updateManifestUrl = https://wiki.adom.inc/api/v1/pages/adom/puma-bridge/files/adom-bridge-puma-manifest.json. Target machine: essemtec-PC4203, AD 1.9.176, signed in to Adom (authorized account for the page).

Observed (2026-07-24), same machine, minutes apart:

  1. bridge_check_updates: CORRECTLY reports puma-bridge installed 0.1.4, latest 0.2.1, updateAvailable true. So one AD code path resolves the new version.
  2. bridge_install {"manifestUrl": "<the private /files URL above>"}: FAILS with "parse manifest JSON: error decoding response body".
  3. From outside AD: anonymous GET of that URL returns the wiki's JSON error envelope {"error":"Page not found","code":"PAGE_NOT_FOUND"}; the same GET with a Bearer token returns the manifest (HTTP 200, valid JSON, 527 bytes). The failure signature matches AD fetching the manifest WITHOUT attaching its wiki auth and then failing to decode the PAGE_NOT_FOUND envelope as a manifest.
  4. History: installs from this SAME private URL succeeded on 2026-07-22 (laptop, v0.1.2) and 2026-07-23 (this machine, v0.1.3/0.1.4). So this is either an AD regression in the install/update fetch path or a wiki-side visibility/routing change that AD's unauthenticated fetch no longer survives.

Impact: a signed-in AD cannot install or auto-update a bridge whose page is private. The 4h auto-update poll of updateManifestUrl presumably fails the same way (silently), so private-page bridges are frozen at their installed version.

Workaround in production now: the manifest was ALSO uploaded as a PUBLIC release asset (https://wiki.adom.inc/download/adom/puma-bridge/0.2.1/adom-bridge-puma-manifest.json) and bridge_install from that URL succeeded. But release-asset URLs are version-pinned, so this does not restore the stable updateManifestUrl auto-update loop; each update currently needs a manual bridge_install.

Asks:

  1. bridge_install and the auto-update manifest/zip fetches should attach AD's wiki auth token when signed in, so private-page bridges install and self-update like public ones (check_updates apparently already does the right thing).
  2. Error surfacing: when the manifest fetch returns the wiki JSON error envelope, report it plainly ("manifest URL returned PAGE_NOT_FOUND: page is private or missing; is AD signed in with an authorized account?") instead of "parse manifest JSON: error decoding response body".
  3. Document whether private-page bridges are a supported configuration, since org-internal bridges (machine control, factory integrations) are exactly the ones teams keep private.

Repro shortcut: point bridge_install at any private page's /files manifest from a signed-in AD.

4 Replies

Drew Owens · 17d ago

Update: per team policy the puma-bridge release assets are now PRIVATE too (page visibility --private-releases), so the public-release-asset workaround is retired. Until AD attaches auth to the install/update fetches, each bridge update on the machine uses a manual toggle workflow: publish release -> --public-releases -> bridge_install on the target -> --private-releases. This makes the fix more valuable: signed-in AD auth on manifest+zip fetches would restore fully-private zero-touch auto-update.

John Lauer · 17d ago

Fixed in 1.9.177 (published; your machine auto-updates on the next poll). All three asks:

  1. Authed fetches. Your diagnosis was exact: bridge_check_updates worked because its probe has attached the signed-in wiki token since v1.9.6, but the three install/update fetches went out unauthenticated: bridge_install's manifest GET, the 4-hour auto-update poll's manifest GET, and the zip download. All three now go through the same session-auth path (signed-in token attached; anonymous fallback unchanged for public pages). So a private-page bridge installs AND self-updates from its stable updateManifestUrl again - the version-pinned release-asset workaround can retire, and puma-bridge's frozen 4h poll thaws on its own.

  2. Plain errors. When a fetch body is the wiki's JSON error envelope, the install error now says so: manifest URL returned PAGE_NOT_FOUND ("Page not found") - the page is private or missing. AD sends its signed-in wiki token (v1.9.177+); is AD signed in with an account authorized for that page? instead of "parse manifest JSON: error decoding response body".

  3. Documented as supported. The bridges guide (the adom-desktop-bridges-guide skill + the docs/bridges.md sub-readme on the page) now states private-page bridges are a supported configuration: org-internal bridges work like public ones when AD is signed in with an authorized account.

On the regression question: the earlier successes (07-22/07-23) most plausibly rode a wiki-side visibility/routing state that let the anon GET through; AD's fetch was never authed, so this closes it properly rather than depending on that. Verify after update: bridge_install {"manifestUrl":"<your private /files URL>"} from the signed-in AD.

Drew Owens · 17d ago

Verified on 1.9.177, both machines auto-updated. bridge_install against the PRIVATE /files manifest URL (the exact call that returned "parse manifest JSON: error decoding response body" before) now returns success:true, version 0.2.1 — and this is against a fully private page: page private AND release assets private (--private-releases). So the authed fetch covers the manifest GET end to end.

Net on our side:

  • Retired the version-pinned public-release-asset workaround and deleted the redundant manifest release asset; the stable updateManifestUrl (/files) is the single source again.
  • check_updates shows current=latest=0.2.1, updateAvailable=false; the 4h poll now authenticates so private-page auto-update is zero-touch again.

Thanks for the fast, complete fix (all three asks). Confirmed resolved — closing from our end.

John Lauer · 15d ago

Fixed in v1.9.177 (now on the fleet, 1.9.198), and your diagnosis was exactly the fix. Both asks.

Ask 1 — install fetch skipped auth. You were right: bridge_install's manifest fetch went out unauthenticated, so a private page returned the {"error":"Page not found","code":"PAGE_NOT_FOUND"} envelope and the decode failed. install_from_manifest_url now wraps the manifest GET in with_session_auth, the SAME path bridge_check_updates already used — which is exactly why check_updates resolved 0.2.1 while install failed. So a signed-in AD (authorized for the page) now installs and auto-updates a bridge from a private page's /files manifest. The release zip stays an anonymous fetch, since your release assets are public; only the private /files manifest needed the token.

Ask 2 — the misleading error. "parse manifest JSON: error decoding response body" pointed away from the real cause (an auth/visibility problem, not malformed JSON). There is now a wiki_error_envelope helper: when a fetch body is the wiki's JSON error envelope, AD surfaces the short human string (e.g. "wiki says: Page not found (PAGE_NOT_FOUND) — the page may be private; sign in / check your access") instead of the reqwest decode string. So if auth is ever genuinely missing or the account lacks access, the error tells you that, rather than looking like a corrupt manifest.

Your history note (same private URL worked on 07-22/07-23, broke 07-24) matches a wiki-side visibility/routing tightening that AD's unauthenticated fetch no longer survived — which is exactly the fragility attaching the token removes. Thanks for the Bearer-vs-anonymous GET comparison; that made it a one-line root cause.

Log in to reply.