← Commit history
SKILL.md+1−1
@@ -56,7 +56,7 @@ adom-bridge serve --stop                 # stop the watchdog + relay `serve` (plain, foreground) still works and prints a loud hint telling you it will die with the session — fine for a quick local relay you'll sit and watch. **Caveat:** a full CONTAINER REBOOT still needs a boot hook (cron `@reboot` / the container's init); the watchdog covers session teardown, not host reboot.
 
 This starts:
-- WebSocket server on `0.0.0.0:8765` (desktop app connects here)
+- WebSocket server on `127.0.0.1:8765` (desktop app connects here; `--bind 0.0.0.0` / `ADOM_RELAY_BIND` to listen on the network, 2.1.170 wiki #225)
 - HTTP API on `127.0.0.1:8766` (CLI commands go here)
 
 Check if it's running:
dist/linux/adom-bridge
⋯ 1 unchanged line ⋯
package.json+1−1
@@ -1,6 +1,6 @@ {
   "slug": "adom-bridge",
-  "version": "2.1.169",
+  "version": "2.1.170",
   "type": "app",
   "brief": "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-only permission system keeps you in charge of every side-effecting command.",
   "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",
page.json+1−1
@@ -1,6 +1,6 @@ {   "slug": "adom-bridge",-  "version": "2.1.169",+  "version": "2.1.170",   "type": "app",   "description": "Install this package in a cloud or Hydrogen Desktop container, not on the PC. It delivers two things: the Linux adom-bridge-cli (linked onto PATH) and the Claude skill set that teaches an AI every desktop verb (shell, files, screenshots, windows, notifications, KiCad, Fusion 360, browser automation). The CLI drives the Adom Bridge app running on your Windows PC over the relay; the Windows app itself is the separate installer in the Download box, not part of this package. Run adom-wiki pkg update to keep the CLI and skills current.",   "keywords": [
skills/adom-bridge-cli-guide/SKILL.md+5−1
@@ -164,7 +164,11 @@ container's init); the watchdog covers session teardown, not host reboot.  What `serve` binds: -- WebSocket on `0.0.0.0:8765` (desktop apps connect here)+- WebSocket on `127.0.0.1:8765` (desktop apps connect here). Before 2.1.170 this was+  `0.0.0.0`; under Hydrogen's mirrored WSL networking that put it on the Windows host's+  LAN interfaces, accepting the dev token (wiki #225). `--bind 0.0.0.0` (or+  `ADOM_RELAY_BIND=0.0.0.0`) opts back in when a desktop must connect over the network+  directly, e.g. a `docker -p` relay; the relay then prints a warning. - HTTP API on `127.0.0.1:8766` (CLI commands go here)  Health check: `curl -sf http://127.0.0.1:8766/health`. If another relay is already
skills/adom-bridge-recording/SKILL.md+1
@@ -13,6 +13,7 @@ description: Record the user's screen with Adom Bridge's NATIVE recorder (v2.1.3 - `desktop_record_encoders` lists the codecs this box can hardware-encode: `{codecs:{h264:{available,hardware,encoders:[{name,hardware}]}, h265:{...}}, default:"h264"}`. h264 is the default (most compatible). **HEVC works** too: `codec:"h265"` records an HEVC MP4 (~40% smaller at similar quality; needs a modern player). HEVC uses the GPU path (a D3D11 VideoProcessor makes NV12 for the hardware H.265 encoder), so `gpu:false` is ignored for h265. `fps` is a start arg too.
 - **Choosing a mode (read this before you pass any encoder option):** say nothing and you get the tuned default: peak-constrained VBR, exact length, a still screen costs almost nothing, fast motion stays sharp. Pass `bitrate` only for a hard cap you actually need (a slow disk, a size limit). Pass `quality` only on content you know is not video or noise (no cap in that mode). Pass `codec:"h265"` when the player is modern and you want half the file. The worked examples with measured numbers and the five example clips: https://wiki.adom.inc/adom/adom-bridge/files/docs/recording.md
 - Rate control (v2.1.128, John: fast motion went splotchy under the old bits-per-second cap): the DEFAULT is peak-constrained VBR with a mean of 3x the old resolution-derived target (about 33 Mbit/s at 1440p30, 72 at 4K) and a peak of 2x the mean. A still screen costs almost nothing (measured 0.34 MB for a 14 s still page) and fast motion gets up to the peak instead of smearing (a noise-field stress page: 30 Mbit/s and readable text, where the old 11 Mbit/s CBR was mush). `bitrate` (bits/s) switches to CBR at that rate when you need a hard cap; `maxBitrate` sets the VBR peak; `quality` 1..100 selects constant-quality mode, which the NVENC MFT does NOT cap (185 Mbit/s on the noise page at 75), so only ask for it on content you know. The start reply and status carry `rateControl` (vbr | cbr | quality).
+- The mouse pointer (v2.1.170, wiki #226): `cursor` (default `true`) on `desktop_record_start` and `desktop_record_window_start`. Pass `cursor:false` for an AI-driven demo of a background window: the AI's input does not move the system pointer, so the only pointer in the take would be the USER's, wandering across the window while they do something else. The start reply and status carry `cursorCaptured` (what Windows actually applied). Hiding the pointer needs Windows 10 2004 or newer; on an older build the pointer stays in and `cursorNote` says so.
 - Status carries the encoder's own counters: `encodedFrames`, `encodeBacklog` (received minus encoded), `sinkOutstanding`, `encodeFps`, plus `droppedFrames` (pool empty, or ticks skipped because the encoder was more than 2 s behind). A rising `encodeBacklog` or a low `encodeFps` at a big resolution means the encoder cannot keep up: pass a lower `bitrate` / `fps`, or record a window instead of a 4K monitor.
 - The timeline is WALL-CLOCK EXACT (v2.1.125, wiki #195). Windows Graphics Capture delivers a frame only when the screen content changes, so a still screen yields few frames and a tiny file, and a moving screen yields the full frame rate; the encoded duration equals the take's wall clock in both cases (a frame count far below fps x seconds is normal, not lost time). ab stamps every frame on the take's wall clock and, after the MP4 is closed, rewrites the container's per-frame durations from those stamps (the Media Foundation fragmented-MP4 sink gives the last frame of every 2 s fragment a duration of 1/fps whatever the real gap was, which is what used to shorten still passages). The stop/status payload reports it as `timeline: {repaired, fragments, samples, endBeforeMs, endAfterMs}` (`repaired:false` + `reason:"no fragments"` for the h265 container, which is not fragmented and already carries exact durations). A held frame is re-written at most every 2 s so any player can seek into a long still passage.
 - Status: `desktop_record_status {"recordingId"?}`; no id lists every registered take (`autoStopped:true` = it hit `maxDurationMs`, call stop to collect it).
skills/adom-bridge/SKILL.md+1−1
@@ -56,7 +56,7 @@ adom-bridge serve --stop                 # stop the watchdog + relay `serve` (plain, foreground) still works and prints a loud hint telling you it will die with the session — fine for a quick local relay you'll sit and watch. **Caveat:** a full CONTAINER REBOOT still needs a boot hook (cron `@reboot` / the container's init); the watchdog covers session teardown, not host reboot.
 
 This starts:
-- WebSocket server on `0.0.0.0:8765` (desktop app connects here)
+- WebSocket server on `127.0.0.1:8765` (desktop app connects here; `--bind 0.0.0.0` / `ADOM_RELAY_BIND` to listen on the network, 2.1.170 wiki #225)
 - HTTP API on `127.0.0.1:8766` (CLI commands go here)
 
 Check if it's running: