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

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

Kyle Bergstedt · 3mo ago ·closed by John Lauer

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.

2 Replies

John Lauer · 2mo ago

I could not reproduce this (no macOS box here), but I can rule out the most likely explanation and give you a precise next step, because the code says something different from what the report assumes.

Prefix matching is not the problem. bridge_registry::resolve_verb checks EXPLICIT verbs before prefixes:

for b in bridges { if b.verbs.iter().any(|v| v == verb) { return Some(b); } }   // explicit
for b in bridges { if b.verb_prefixes.iter().any(|p| verb.starts_with(p)) { ... } }  // prefix

So a bridge that declares nbrowser_status in verbs routes even with no verbPrefixes at all. Since your bridge_info showed the full nbrowser_* verb list declared, the verb WOULD have resolved if the bridge had been in the list the dispatcher was given.

Which means the registry the dispatcher saw did not contain native-browser. That is consistent with your other two observations and is the thing to chase: status.desktop.apps showed only {browser, fusion360, kicad, shell} - no native-browser either. Both of those read a registry; bridge_info may have rescanned and found it while the in-memory list the dispatcher uses did not have it. So this is a registry-membership/scan divergence, not a verb-routing bug.

What would settle it in one command, on the affected machine:

adom-bridge --target <mac> bridge_list '{}'

If native-browser is ABSENT from bridge_list while bridge_info native-browser still describes it, that is the divergence, and the two calls disagreeing is the bug report I need. If it is PRESENT in bridge_list with its verbs and the dispatch still 404s, that is a different and more interesting bug and I want to see both outputs together.

Also worth noting: you were on 1.9.183, and the registry/scan paths have had substantial work since (2.0.x), including duplicate-collapse and adoption fixes that change what ends up in that list. A re-test on current is cheap and may simply resolve it.

Leaving this open rather than closing it as stale - it was a real outage for you and I would rather have the bridge_list output than assume it aged out.

John Lauer · 2mo ago

Closing for lack of a repro: no macOS box here, and the analysis above narrows it to "the registry the dispatcher saw did not contain native-browser" with a precise next step (bridge_list at the moment of the failing call, and whether the cache bridge.json declares the verbs). Reopen with that output and I will take it from there; nothing further can be done blind.

John Lauer closed this · 2mo ago