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 bug report

macOS AD 1.9.183: nbrowser_* verbs unroutable ('no installed bridge claims this prefix') while native-browser bridge is live

Kyle Bergstedt · 12d ago

Setup: cloud container CLI 1.9.214 (626b8fc-dirty) → relay → macOS AD 1.9.183 (update_check says latest for channel) on Kyles-MacBook-Pro.local.

What I ran: adom-desktop --ai-thread ... nbrowser_status '{}' (also nbrowser_profiles, nbrowser_open_window, with and without --target)

Expected: routed to the native-browser bridge, which is running: bridge_info shows name=native-browser v0.1.54, processLive:true, port 58492 (host tcp 58497), full nbrowser_* verb list declared, bridge_readiness state:ready.

Got (verbatim, ~10ms, every time): {"durationMs": 10, "error": "Unknown verb 'nbrowser_status' — no installed bridge claims this prefix", "output": "", "status": "error", "success": false, "timeoutSeconds": 30}

Diagnostics:

  • status → desktop.apps = {browser, fusion360, kicad, shell} only; no native-browser entry.
  • hd_status → "Unknown app: hd" — dispatch appears to be by a fixed app map on this build.
  • kicad_nonexistent → "Unknown command: nonexistent" (523ms, reached the bridge) so kicad_ prefix routes fine.
  • Relay restart and refresh_bridges did not help. Same result with explicit --target.

Read: the macOS 1.9.183 core spawns and supervises the native-browser bridge (wiki-updated to 0.1.54) but never wires the nbrowser_ prefix into its verb router, so the bridge is running yet unreachable from any caller. Windows builds ≥1.9.2xx presumably have the dynamic prefix claim. Ask: backport dynamic bridge-prefix routing to the macOS channel or ship a mac build ≥ the routing change.

0 Replies

Log in to reply.