app

Adom Desktop

Public Made by Adom

by adom

Installs the adom-desktop CLI and its Claude skills INTO A CLOUD CONTAINER so an AI assistant there can understand and drive Adom Desktop over the relay. This is the container side, NOT the app itself. The Adom Desktop app is the signed Windows installer under Download below: run THAT on the PC you want the AI to control. Rule of thumb: pkg install here (in your Linux container), Download there (on your Windows PC). Once installed, the AI can drive file transfer, screenshots, notifications, KiCa

adom-desktoptauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues6 Breadcrumbs Pull Requests Activity
Closed general

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

John Lauer · 23d 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 · 23d 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.