Unleash your AI onto your full PC: full power, full safety. Every AI you use today is locked in a box: a cloud agent lives in a container with no hands, and a chat app can talk about your files but cannot touch them. Adom Bridge inverts that. It lets the AI break out of the box it runs in and onto your real machine, so the AI manages and runs your entire laptop as you, without you doing anything manually: launch apps, move files, drive any window, control KiCad, Fusion 360, Altium, Blender, or your real signed-in browser. It does not matter where your AI lives. A cloud agent reaches your desktop over the relay; a local one (Claude Desktop, Claude Code, Codex, anything) drives the same machine over loopback. It ships with Hydrogen and installs standalone too, and standalone users get the full value.
Bridges make Adom Bridge a small operating system for AI: a bridge teaches it a new verb namespace for any app, and Adom Bridge provisions its own managed Node and Python runtimes, owns the bridge lifecycle, and keeps every bridge in a controlled loopback-only environment. And because unleashing an AI onto a whole machine only works if the human stays in charge, the permission system is the other half of the product: side-effecting commands from a remote AI are gated behind a human approval the AI can request but never grant itself, every command is attributed to the AI thread that issued it, and Adom Bridge binds to localhost only. Full power and full safety together are the point.
http://127.0.0.1:24680 on your machine. If Adom Bridge is running, the buttons below reach it. Nothing changes your machine without a permission prompt you click. The long ones (launching KiCad, Fusion, a board) run synchronously on Adom Bridge and stream live status back over one connection, then show a screenshot to prove it really happened.Ready. Click "Detect Adom Bridge" to begin.
The cloud AI never touches your machine directly. It sends a verb to the relay; Adom Bridge, connected out to that relay from your desktop, executes it against Windows or forwards it to a bridge, and streams the result back. A co-resident sibling app (Hydrogen) can skip the relay and POST straight to the loopback HTTP API at 127.0.0.1.
Adom container (this package) User's laptop
+--------------------------+ +--------------------------+
| adom-bridge + skills| <-relay-> | Adom Bridge GUI (Tauri) |
| (Claude drives verbs) | | KiCad, Fusion, Chrome |
+--------------------------+ | shell, files, screens |
+--------------------------+
adom-wiki pkg install adom/adom-bridge
That installs the container-side pieces: the adom-bridge binary (SHA256-verified against this page's version.json) and the Claude skill bundle into ~/.claude/skills/:
| Skill | What Claude learns |
|---|---|
adom-bridge |
the main verb catalog: screenshots, files, shell, windows, notifications |
adom-bridge-notify |
native Windows toasts: progress bars, sticky reminders, buttons that round-trip |
adom-bridge-sdk (+ -manifest, -runtime, -callback, -publish, -audit) |
author your own bridge: a skill library split by phase, so only the part you need loads |
adom-bridge-ownership |
the boundary: what Adom Bridge core owns versus what a bridge author owns |
adom-bridge-multi-machine |
address multiple Adom Bridges on one relay (--target, fan-out) |
adom-bridge-direct-api |
the loopback HTTP API for sibling apps |
adom-bridge-installer, adom-bridge-windows-host, adom-bridge-discovery |
install, host, and discovery details |
adom-wiki pkg update keeps it current. The KiCad and Fusion 360 bridge skills install from their own cloud-owned bridge pages.
You do not need the cloud, and you do not need to be an Adom container user. Installing Adom Bridge makes a local Claude Desktop, Claude Code, or Codex a full Adom ecosystem citizen: it drives your PC (no relay, no setup), automates a real browser via the bundled pup bridge, authors wiki pages with the bundled adom-wiki.exe, and reaches into your cloud Hydrogen workspace (webviews, sandboxes, screenshots) with the bundled adom-cli.exe. Auth rides your one Adom Bridge sign-in, and the ecosystem skills are delivered and kept fresh automatically, each stamped with a note explaining how it applies on a container-less Windows PC. The one thing a local agent cannot do is run wiki-published Linux binaries; that needs an Adom container, which is what Adom Hydrogen provides. Full story: Adom Anywhere; local routing details: using Adom Bridge from a local AI.
Sign in to your Adom account inside the app (Connections panel) and your cloud containers appear in the connection list and connect automatically: no JSON, no copy-paste. An AI in a container registers itself with one command. Deep dive: sign-in and cloud configuration.
One desktop can connect to many containers, many desktops can share one container, and both at once. Address any desktop by name with --target. Deep dive with a topology diagram: connection topology.
Every Adom Bridge signed into your account finds the others through the Adom Mesh: relay mode by default (nothing listens on your PC; boxes talk through the Adom-hosted mesh relay, end-to-end encrypted on per-machine keys), direct mode on the same network if you switch it on. A human trusts each new machine into the mesh with one click that settles every box. And a permission prompt raised on any of your machines appears on all of them, with a chip naming the box it belongs to; decide it wherever you are, in Adom Bridge or (2.1.75) in Hydrogen's own dialog, and the decision lands on the origin. Deep dive: the Adom Mesh and cross-box permission prompts.
When Hydrogen is present it runs Adom Bridge embedded: hidden window, Hydrogen-owned permission prompts, and a distinct taskbar tile. If Hydrogen ever goes away, Adom Bridge comes back standalone so your machine stays reachable. Deep dive: how Adom Bridge interacts with Hydrogen.
The Windows GUI installs separately: a signed NSIS installer served from this page (Download for your machine above; Hydrogen installs it automatically). It installs to %LOCALAPPDATA%\Adom Bridge\, adds a tray icon, starts on login, and auto-updates itself from this page's version.json (prompt by default; every 4h and on launch).
The main window (top) puts everything on one surface: Connections (each relay plus the other Adom Bridges on it as peers), the Activity Log (every command, badged by source and type, filterable), the Bridges sidebar (installed bridges as mini-app cards), the provisioned Runtimes, and the footer approval bar.
Deep dives: presence, tray and icon states and the managed Node and Python runtimes.
Everything a real user installs comes from this page.
| Artifact | Platform | What it is | How to get it |
|---|---|---|---|
| Signed installer (NSIS) | Windows x64 | The GUI desktop app. Azure Trusted Signing. Installs to %LOCALAPPDATA%\Adom Bridge\ and auto-updates. |
The Download for your machine box at the top of this page. This is the one promoted Windows download. |
| CLI + skills package | Linux (container) | The adom-bridge binary and Claude skill set for a cloud container driving your desktop remotely. Not needed if you use Hydrogen, which bundles Adom Bridge. SHA256-verified on install. |
adom-wiki pkg install adom/adom-bridge |
version.json |
manifest | The auto-update manifest the GUI polls: per-platform installer URL, SHA256, and size. | Read automatically by the app; you never fetch it by hand. |
The Windows GUI installer is the only promoted Windows download. There is intentionally no standalone Windows CLI download. macOS is planned; the manifest reserves a slot for it.
Adom Bridge polls the wiki manifest on launch and every 4 hours. Every release is Azure code-signed and its installer is SHA256-verified before it runs. What differs is urgency, and the manifest carries a priority:
| Tier | How it is presented | Overrides your mode? |
|---|---|---|
| Normal | Almost every release. A footer banner: Install now / Later. Silent in Auto, nothing in Off. | No. |
| High | A recommended fix. Auto-installs in the background (even in Prompt) with a heads-up toast, then restarts. | Overrides Prompt; still respects Off. |
| Emergency | A bug bad enough to pull from the whole fleet at once. A red, non-dismissible countdown to a forced restart; Adom Bridge Authenticode-verifies the installer (must be signed by Adom Industries) before it runs. | Overrides everything, even Off, even embedded. |
You set your preference once in Settings, Updates: Prompt (default), Auto, or Off. A normal release carries no priority; the emergency tier is a deliberate, per-incident action.
When a normal update actually installs. Adom Bridge lives in the tray and can run for weeks without a restart, so a Prompt-mode update you never click would never install. The restart schedule closes that: once an update is downloaded AND you have been away from the keyboard for about 15 minutes AND Adom Bridge is not mid-task, it installs and relaunches quietly. It is idle-based, not a fixed clock, so it never interrupts active work or an overnight job, and restarting Adom Bridge has no effect on your other apps (it reconnects in seconds). Turn it off in Settings, Updates, "Restart when idle to finish updates," and a Prompt-mode update simply waits for your click. Auto installs immediately; Off never auto-installs (except an Emergency release). Embedded in Hydrogen, Hydrogen owns the restart timing.
Deep dive on every update lane (app, bridges, container package, skills) and the network-traffic math: how updates work.
Anything Adom Bridge can see, it can screenshot, losslessly, with no focus steal (PrintWindow or full-screen DXGI, never a foreground grab). Every image on this page was produced by these verbs. desktop_screenshot_window returns a screenshots[] array: the window plus each owned popup or child dialog as its own image (so a confirm bubble hovering over an app comes back alongside the parent, never missed); desktop_screenshot_screen grabs the full virtual screen including borderless popups; pup_screenshot grabs the pup viewport. Every shot carries a coordMap so the AI clicks what it sees ({space:"image", shotId, x, y} to real screen px, no DPI math). It stays generic: Adom Bridge returns the rich array, the AI decides. ad_scroll even lets the AI page Adom Bridge's own window to capture content below the fold.
Adom Bridge records the desktop or a browser session to video. The recorder HUD (above) requires a reason shown to the user up front, so a recording never starts silently, with live Screen/Microphone toggles and a Start/Stop control. desktop_recorder_open {reason} and desktop_recorder_close for the desktop; pup_record_start and pup_record_stop for the pup browser. Built for smooth, high-frame-rate video, not a choppy screenshot loop.
Deep dive: recording.
Each bridge is a small, independently-versioned process the app spawns, supervises, health-checks, and auto-updates from its own wiki page. Every install ships with the six below, and each shows up in the Bridges sidebar as a card: its billboard, a health LED, and language/source badges.
pup_*)
A dedicated Chrome-for-Testing (or Edge) that Adom Bridge downloads and manages: open windows and tabs, drive pages, evaluate JS, screenshot, and record. No manual browser install.
nbrowser_*)
Your real, signed-in Chrome or Edge profile, for the logins and forms a throwaway automation profile cannot do. The desktop bridge is bundled and works extension-free out of the box: it discovers your browser profiles, opens URLs in the right signed-in profile (OAuth consent flows), and inventories browser windows. Installing the companion browser extension unlocks full in-page drive: tabs, clicks, JS eval, and background screenshots.
kicad_*)
Schematic and PCB automation: DRC/ERC, gerber and STEP export, 3D board render, and netlist/footprint queries.
fusion_*) plus APS (aps_*)
Parametric modeling scripts and exports, plus fast indexed cloud-file search through Autodesk Platform Services.
blender_*)
Headless Python scripting and renders.
hd_*)
The local dev-environment app Adom Bridge can embed into; Adom Bridge relays Hydrogen's runtime state and drives its lifecycle.
Install a third-party bridge by pasting its manifest URL, or bridge_install {"manifestUrl":"..."}.
Deep dive: bridges from the user's side (cards, LEDs, console, installing and updating).
The bridges above are not special: they are ordinary bridges, and you can add your own. A bridge is a small local program in any language that serves HTTP on localhost. Adom Bridge spawns it, keeps it alive, and routes a namespace of verbs to it, so kicad_* reaches the KiCad bridge and yourprefix_* would reach yours.
Adom Bridge core owns the machine: spawning, ports, health, permissions, screenshots, files, windows, and the relay. You own your app and what its verbs mean. Runtimes are handled for you, a portable Node and Python with no elevation prompt, and your bridge inherits the human-approval permission model rather than inventing one.
In practice the AI builds the bridge. The reference is a library of skills that ship in this package (adom-bridge-sdk and its manifest, runtime, callback, publish and audit companions), so an AI loads only the phase it is working in. Two minimal working bridges, hello-python and hello-rust, are there to copy.
Deep dive: build your own bridge, the illustrated tour of what a bridge is, what the user sees, and the three things you publish.
Adom Bridge's window carries a mode-specific app identity, so the taskbar button swaps its whole tile AND its name the moment the mode changes: no restart, no flicker.
| Icon | Mode | Taskbar name | Meaning |
|---|---|---|---|
 |
Standalone | Adom Bridge | Adom Bridge running on its own. The default for a normal install. |
 |
Embedded | Adom Bridge Hydrogen Embedded | Hydrogen launched Adom Bridge and drives its lifecycle. |
Muted "Adom Bridge" = Adom Bridge by itself; vivid "Adom Bridge Hydrogen Embedded" = Hydrogen has the helm. Each mode is a registered Windows app identity, and flipping the window between them makes the shell rebuild the button with the other identity's icon and name. Because the modes are distinct identities, a taskbar pin made in one mode shows the running window as a separate button while Adom Bridge is in the other mode.
The same Windows shell mechanism (the Application User Model ID, or AUMID) is exposed as generic verbs so a bridge can make a window it drives present as its app. The motivating case: a Chrome for Testing window that would otherwise read "Test" with Chrome's icon in the taskbar, Alt-Tab, and the right-click menu.
desktop_register_app_identity teaches Windows what an app id means (name plus icon), HKCU only, no UAC; shortcut:false gives a per-session identity with no Start Menu spam.desktop_set_window_identity stamps that id onto a live window plus its title-bar and Alt-Tab icon and the jump-list header.desktop_set_window_jumplist attaches a custom right-click menu and brands its header row.desktop_taskbar paints a progress bar, an overlay badge, and the hover-preview tooltip (thumbnailTooltip, the one uncapped text surface) and clip on any window's button.These verbs inspect any icon you pass and return an iconCheck that explains, in plain terms, why an icon renders as a generic white document (the 256px .ico size must be PNG-compressed; SVG does not load; a .ico uses a bare path while a .exe uses path,index), so the caller fixes the file instead of shipping a broken icon. The full guide ships as the adom-bridge-window-identity skill.
Auto-connect behavior, the update channel (prompt / auto / off) and restart when idle to finish updates, the shell-approval preference, Hydrogen integration (including exit when Hydrogen exits), and runtime prewarming. While embedded in Hydrogen, Hydrogen-owned preferences show as managed by Hydrogen.
The trust boundary is install-consent plus the localhost bind. Installing the app (and each bridge) is you granting permission for the AI to drive your machine; if you do not want that, uninstall. And the app plus every bridge binds 127.0.0.1 only, never 0.0.0.0, so a caller must already be a program you installed on your own machine to reach it. No network attack surface by construction.
On top of that, the remote cloud-AI path is approval-gated. Verbs that run code or change the machine (shell_execute, run_script, launch_process, write_file, registry_*, process_kill, and so on) require a human grant when they arrive over the relay: +1hr / +24hr (time-boxed), Bypass (indefinite), or Revoke. The grant is human-only; local callers (your CLI, Hydrogen, bridges) are trusted by transport and never prompt; read-only verbs are never gated.
Deep dive: permissions (what each Approve choice means, and how to revoke).
Adom Bridge speaks to you through native Windows toasts via notify_user, under Adom Bridge's own identity (the Adom logo, and Action Center history like any first-class app). A cloud AI or a bridge, even one on a different machine addressed with target, fires them to reach you wherever you are. Every image below is the real toast, captured live from the exact call shown.
Basic alert. Awareness: a build finished, a file is ready. Auto-dismisses in about 7 seconds. Add "durationLong":true to hold it around 25 seconds; "level":"error" and up do that automatically, and "emergency" also flashes the taskbar.
adom-bridge notify_user '{"title":"Export done","body":"gerbers.zip is ready in C:/exports."}'
Click-to-focus: send them where the notification points. Most notifications are about something else on screen: a browser waiting on a login, a dialog, an app that needs a click. Pass focus and clicking the notification brings THAT window to the front, instead of opening Adom Bridge. Name the window by hwnd (exact, from desktop_list_windows), by cacheKey, or by titleContains.
adom-bridge notify_user '{"title":"Sign-in needed","body":"Confirm in the browser and I will continue.","focus":{"titleContains":"Sign in - Google Chrome"}}'
The response says whether the target resolved, so the AI finds out at send time rather than you finding out by clicking a notification that does nothing. If the window is gone by the time you click, it falls back to opening Adom Bridge, so a click is never dead. The click also counts as an acknowledgement, so the AI learns you engaged even with no buttons on the toast.
Sticky choice with buttons that round-trip. Stays on screen until the user clicks (no auto-dismiss). Give it an id you choose, then read the click back.
adom-bridge notify_user '{"id":"deploy-42","title":"Ship v2 to production?","body":"The build is green and staged.","scenario":"reminder","buttons":[{"label":"Ship it"},{"label":"Hold"}]}'
Progress bar. For a long job (a gerber export, a render). Re-fire with the SAME id as the job advances toward 1.0. body is optional here.
adom-bridge notify_user '{"id":"job-1","title":"Exporting gerbers","progress":{"title":"myboard.kicad_pcb","value":0.6,"status":"Plotting copper layers...","valueOverride":"6 / 10 layers"}}'
Reply input. The text field renders, but Windows does not return typed text over protocol activation, so it is display-only today. For a real choice, use buttons.
adom-bridge notify_user '{"title":"Quick note","body":"Leave a note for the next run.","scenario":"reminder","inputs":[{"id":"reply","type":"text","placeholder":"Type a reply..."}],"buttons":[{"label":"Send"}]}'
Shell-approval. Fired by Adom Bridge itself when a gated command needs a human: Approve 1 hr / 24 hr / Bypass Permissions, granted straight from the toast without opening the window.
How the AI tracks the response, or expires the notify. A toast is fire-and-forget, but a clicked button is recorded durably, so the AI learns the outcome even on a headless box:
adom-bridge notify_response '{"id":"deploy-42"}' # pending:true until clicked, then action:"Ship it"
adom-bridge notify_events '{"sinceSeq":0}' # drain EVERY click since a cursor, no per-id polling
adom-bridge notify_dismiss '{"id":"deploy-42"}' # retract a sticky toast once you have handled it
Or skip the polling entirely with "wait":true, which blocks until you act (or timeoutSec elapses) and hands the AI your answer directly.
Clicking the toast body brings the window named by focus to the front, or opens Adom Bridge when no focus was given. Button clicks deliberately do not steal focus: a toast exists to reach you without interrupting what you were doing.
The AI does not have to read any of this first. When a call leaves something on the table, such as no focus, or buttons on a toast that will vanish before you see it, the response says so and lists what the verb can do. That coaching stops once the AI gets it right. Full reference lives in the adom-bridge-notify skill.
Deep dive: notifications.
Adom Bridge core owns the generic verbs (desktop_*, shell, ui_*, files, notify_user, multi-machine). Each bridge owns its own prefix and ships its own verbs; the app relays them verbatim and stays generic. Invoke the same way on every transport, for identical JSON back:
adom-bridge screenshot_window '{"hwnd": 12345}' # CLI (relay / direct API)
adom-bridge --target AzureVM list_windows # target a named machine
curl -s -X POST 127.0.0.1:24680/command \
-d '{"command":"notify_user","args":{"title":"Hi"}}' # loopback direct API
adom-bridge help and GET /commands are the live discovery surfaces for the full verb set.
Deep dive on the CLI itself: the CLI guide.
Adom Bridge serves a couple of small pages on its loopback HTTP API (the stable port 127.0.0.1:24680), so you can inspect it from a normal browser:
http://127.0.0.1:24680/verbs is a browsable API Explorer: every verb, grouped into tabs by category and with one tab per installed bridge, each with a plain-English description and a copy-to-clipboard curl command. The footer tooltip in the laptop GUI links straight to it. GET /health, /status, and /commands return the same information as JSON.
Web Control (detection). A page served from https://wiki.adom.inc can fetch('http://127.0.0.1:24680/health') (and /status) to detect whether Adom Bridge is running, so the wiki can light up actions like "open this component in KiCad." The detection reads are deliberately tight: Adom Bridge returns CORS headers only for the exact origin https://wiki.adom.inc (never a wildcard, never a user-provisionable *.adom.cloud host) with a loopback-Host check to defeat DNS rebinding, and it handles the Private-Network-Access preflight.
Web Control (running a verb). A web page can also POST /command to ask Adom Bridge to run a verb, but only with the user's permission. Every web request pops a native Adom Bridge prompt in its own window (Allow once / Allow 1 hr / Deny); nothing runs until the user clicks. The consent prompt, not the origin string, is the real gate, so this holds even for the wiki's readme, which renders in a sandboxed Origin: null iframe. The whole surface has a master off switch in Settings > Web Control, and detection keeps working while it is off so a page can tell the user how to turn it back on. Local callers (the CLI, Hydrogen, bridges) are never affected: this is only about web pages in a browser.
Web Control (optional wiki handshake). For users who want more than the consent prompt, Settings > Web Control has a "Require wiki handshake" toggle (off by default). When on, a web page must prove it is really the Adom wiki acting as you before Adom Bridge will even show the prompt: Adom Bridge publishes a per-launch secret to your Adom account's cloud key-value (bridge.webcontrol), and only wiki.adom.inc, signed in as you, can read it and present it back in an X-Adom-WebControl-Secret header. A random site like evil.com cannot read your account key-value, so it is refused outright. This is a stronger gate layered on top of the consent prompt, not a replacement for it, and it could become the default in the future. Full model: the adom-bridge-web-integration skill; the mechanism and the security layers, with diagrams: talking to Adom Bridge from a web page.
This package version tracks the Adom Bridge release. The scaffold is small; the multi-MB binaries are fetched at install time with SHA256 verification (the manifest's assets map carries server-computed checksums per platform).