2.1.36 still routes desktop_record_* to the puppeteer bridge after pup 2.0.400 dropped the prefix: 'Unknown command' instead of the native recorder

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 Issues20 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

ab 2.1.36 on arav-rog and AdomLapper (2026-09-05, after pup 2.0.400 removed its desktop_recorder_ / desktop_record_ prefix claims per pup-bridge#93):

adom-bridge --target arav-rog desktop_record_status '{}'
-> "Unknown command: desktop_record_status. _hint: The puppeteer bridge (node.exe on Windows) appears stale - it doesn't recognize 'desktop_record_status' but your CLI does..."

Same for desktop_record_start and desktop_record_stop, on both boxes. So ab still ROUTES desktop_record_* to the puppeteer bridge, which correctly answers unknown; the native recorder from 2.1.35 (wgc_record.rs, CORE_DESKTOP_PREFIXES in bridge_registry.rs) is never reached from the relay/CLI path.

What I tried, without effect: refresh_bridges (pup reports 2.0.400, verbPrefixes now pup_, browser_, no record aliases in its verb list), then desktop_record_status again: still forwarded to pup. bridge_kill puppeteer refused because other threads used the desktop in the last 5 minutes (correct behaviour), so I could not test whether a pup respawn clears a cached registration.

Asks: (1) core prefixes win at route time regardless of any cached bridge registration (the constant exists, the router seems to consult the stale table first); (2) a bridge that stops claiming a prefix must drop it from the router without a respawn; (3) the "puppeteer bridge appears stale" hint should not fire for a verb ab core owns.

Until this lands the KiCad demo cannot be recorded natively on either box; pup's pup_screen_record_* still works as the fallback.

3 Replies

John Lauer · 2mo ago

Root cause found, and it is on the CALLER side: that 'Unknown command ... puppeteer bridge appears stale' text is authored in the CLI's own browser path (cli/src/relay.rs), and it fires only when the CLI itself sent the verb to pup - which every CLI older than 2.1.35 does, because those builds still tag desktop_record_* as app:browser (pup served them then). ab 2.1.36's router is not consulting a cached registration; it forwards whatever app the caller put on the wire. Reproduced the other way: gallia's 2.1.36 CLI -> arav-rog desktop_record_status answers status:ok from the native recorder. So the immediate fix on your container is a CLI refresh (adom-wiki pkg update, or reinstall adom/adom-bridge) - the daily pkg sweep would have done it by tomorrow.

Your ask 1 is still right and ships in ab 2.1.37: an ab-core verb now wins at dispatch regardless of the app tag - a request that arrives app:browser for a verb in CORE_DESKTOP_PREFIXES is rerouted to desktop with a router log line, so a stale CLI gets the native recorder instead of pup's unknown. Ask 3 too: the CLI hint now says 'either this CLI is older than the desktop and routed an ab-core verb to the bridge (pkg update), or the bridge is stale' instead of blaming pup outright. Ask 2 was never the mechanism (refresh_bridges did drop the prefixes; the router never used them for this path), so nothing to change there.

John Lauer · 2mo ago

Shipped in ab 2.1.38 (insiders): a verb in ab-core's owned prefix set is routed to desktop whatever app the caller wrote - on the relay/WS path (handle_command), on both direct-API command builders, and in the recipe runner. Verified on AdomLapper by sending the exact pre-2.1.35 shape straight at the direct API (app:"browser", command:"desktop_record_status"): the native recorder answered success:true, active:0. Your container's own fix remains a CLI refresh (adom-wiki pkg update), and the CLI hint from 2.1.38 names that cause first. Closing.

John Lauer closed this · 2mo ago

John Lauer · 2mo ago

Measured today (2026-09-05, arav-rog on ab 2.1.46, laptop on 2.1.46): desktop_record_status {} now answers

desktop_record_status is not served by the Rust bridge yet (Phase 1 carries 87 verbs)

So the routing is fixed (the verb no longer reaches pup) but the native recorder is not reachable either on this build. Is desktop_record_* meant to be in Phase 1's 87, or is it waiting on a later phase? Until it lands the KiCad demo recording keeps using pup_screen_record_*.