app
Adom Bridge
Public Made by Adomby 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
← Commit history
Publish 2.1.167
4 files changed
+6−2
dist/linux/adom-bridge⋯ 1 unchanged line ⋯
package.json+1−1@@ -1,6 +1,6 @@ { "slug": "adom-bridge", - "version": "2.1.166", + "version": "2.1.167", "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.166",+ "version": "2.1.167", "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-mesh/SKILL.md+4@@ -20,6 +20,10 @@ One person, several boxes, one account. Every Adom Bridge (2.1.40+) carries a du `pull_file --target <peer>` and the automatic screenshot pull now go over the direct mesh path when the peer is reachable: the file streams peer -> your ab -> your disk with a sha256 check, no relay host in the middle (the relay's streamed pull only lands files on the relay host, which helps a container CLI but not a desktop). The reply carries `route.via = "mesh"` and `savedTo`. A screenshot of a mesh peer (`--target crr desktop_screenshot_screen`) therefore arrives locally like a local one. Falls back to the relay when the mesh cannot reach the peer. +`send_files --target <peer>` goes over the mesh too (2.1.97): the CLI asks the peer where the files would land, then streams them through the local Adom Bridge in 768 KiB chunks, sha256-verified on the peer (`route.via:"mesh"`). A peer that is reached over the mesh but is not on your relay ("mesh-only" in `targets`) takes files exactly like any other peer. + +**A refusal is the answer, not a routing failure (2.1.167).** When the peer is reached and says no (a `dest` outside its user folders is `bad_dest`, a file still being written fails its sha256 check, a gated write needs approval), the reply is that refusal with `route.via:"mesh"` and the peer's own reason in `error`. The CLI only falls back to the relay when the peer could not be reached at all. Before 2.1.167 a refusal fell through to the relay, which answered `target_not_found`, and an AI concluded the box could not take files. If you see `target_not_found` with `routeSupport.meshViaLocalAb`, read that field: it says why the mesh route did not run. + ## Permission prompts follow you across your boxes (2.1.44; over the relay too since 2.1.59) **2.1.59: this no longer needs the mesh.** The mirror also travels over the hc relay, which every ab is already connected to outbound, so a machine with the mesh OFF (the default) still sees the other boxes' prompts and can decide them, with no firewall dialog ever. The mesh remains the faster direct path and the fallback when the relay is down; a prompt that arrives over both shows once. A decision carries a one-shot nonce the origin stamped into the mirror, so only a human reading a mirrored card on one of your own machines can decide it (an AI on the relay cannot approve its own prompt).