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
Closed general

AD /command passthrough drops top-level `related` and `_next` (forwards only `_hint`)

John Lauer · 1mo ago ·closed by John Lauer

From the native-browser bridge maintainer thread. AD's /command response passthrough forwards a bridge's top-level _hint, but drops related and _next, so the rich-hint contract from the nbrowser_describe amendment is only half-delivered to the calling AI.

Expected (the agreed shape)

The describe/hints amendment specified every /command response should be:

{ "success": true, "output": {…},
  "_hint":   "what you got + what to do next + the pitfall",
  "_next":   "verb_to_call_next",
  "related": ["sibling_verb", "…"] }

_hint is meant to teach a cold-calling AI; _next/related let it chain without re-discovering the surface. All three are part of the same contract.

Observed

The native-browser bridge attaches all three. Verified against the bridge directly (loopback /command):

nbrowser_profiles ->
  _hint   : "List every BROWSER x PROFILE you can drive + which is active…"
  related : ["nbrowser_use_profile","nbrowser_profile_block"]

But the SAME call through AD (adom-desktop nbrowser_profiles / nbrowser_open_window) returns _hint only — related and _next are undefined at the top level. So AD is forwarding _hint and stripping the other two.

Ask

In the bridge /command response passthrough, forward _next and related (top-level) alongside _hint, unmodified. They are optional and may be absent; when a bridge includes them, surface them to the caller (and ideally render them in the Verbs-tab inline-runner result, next to _hint).

Repro

  1. adom-desktop nbrowser_open_window '{"url":"about:blank","focused":false}' (or nbrowser_profiles).
  2. Inspect the response: _hint present, related/_next absent.
  3. Hit the bridge's loopback /command directly with the same verb: all three present.

Bridge: native-browser (v0.0.19), page adom/adom-browser-extension. Note: the describe payload's per-verb hint/related/pitfalls come through fine (they ride inside the verbs array, not as top-level passthrough fields) — this is only about the per-call top-level related/_next.

1 Reply

John Lauer · 1mo ago

Fixed in adom-desktop v1.9.31 (commit ac98d11). command_result_with_meta was an ALLOWLIST that dropped top-level _next/related (and also timeoutSeconds/statusVerb/_ad_note). It is now a DENYLIST: AD relays EVERY bridge top-level field verbatim except the computed success/output/error envelope — so the full rich-hint contract (_hint+_next+related) reaches the caller. Lands on the laptop on the next GUI redeploy; ships to all via the next NSIS.

Log in to reply.