by adom

Your AI's hands in your real, signed-in browser. The Adom Browser Extension (abe) works with both Chrome and Edge: build, drive, and test web apps, and log past vendor walls, in the browser you already use - cookies, SSO, saved logins and captcha trust intact. The nbrowser_* bridge (pup's counterpart) runs in your actual logged-in profile.

Overview Files Skills Discover Packages Releases Dependencies Issues1 Breadcrumbs Pull Requests Activity

Download

install/

Three registrations on a managed Windows machine (golden image / HD / winvm):

Bridge → AD bridges-cache — bridge/ copied to %LOCALAPPDATA%\Adom Desktop\bridges-cache\ native-browser\; adom-desktop's registry auto-discovers it and routes nbrowser_* to it.
Native-messaging host (HKCU, no UAC) — render host-manifest.json from the template (absolute native-host.bat path + the extension ID in allowed_origins) and register it under HKCU\Software\<vendor>\NativeMessagingHosts\inc.adom.native_browser for Chrome and/or Edge.
Extension force-install (HKLM, managed only) — ExtensionInstallForcelist → <id>;<update.xml>.

install.ps1 does all three. Run it OUTSIDE Claude Code.

⚠ The wcifs / AppContainer trap (read adom-desktop/CLAUDE.md)

For Claude-spawned tooling, %LOCALAPPDATA%\Adom Desktop\... is silently redirected to a per-package shadow — PowerShell, Start-Process, and the Write/Edit tool all hit the shadow, not the real path. So from a Claude session, do the bridges-cache copy via WSL2 cp (bypasses wcifs):

cp -r bridge/* "/c/Users/<user>/AppData/Local/Adom Desktop/bridges-cache/native-browser/"

…or via adom-desktop shell_execute. The HKCU/HKLM registry writes and the .bat/manifest writes (under this repo) are NOT in the trapped paths and are fine from PowerShell run outside Claude.

Better long-term: wiki-streamed bridge

adom-desktop already streams bridges from the wiki (bridge_cache.rs / WIKI_STATIC_BASE). Publishing bridge/ as a wiki package lets AD pull + cache it with no manual copy — the preferred delivery once this stabilizes. See the plan's distribution section.

update.xml

update.xml is the self-hosted .crx auto-update manifest the force-install policy points at. Sign the .crx with our own keypair (.pem); the extension ID is the hash of its public key, so reuse the same key for every update. Template lands when we cut the first signed .crx (Milestone 6).

# install/

Three registrations on a managed Windows machine (golden image / HD / winvm):

1. **Bridge → AD `bridges-cache`** — `bridge/` copied to `%LOCALAPPDATA%\Adom Desktop\bridges-cache\
   native-browser\`; adom-desktop's registry auto-discovers it and routes `nbrowser_*` to it.
2. **Native-messaging host (HKCU, no UAC)** — render `host-manifest.json` from the template (absolute
   `native-host.bat` path + the extension ID in `allowed_origins`) and register it under
   `HKCU\Software\<vendor>\NativeMessagingHosts\inc.adom.native_browser` for Chrome and/or Edge.
3. **Extension force-install (HKLM, managed only)** — `ExtensionInstallForcelist` → `<id>;<update.xml>`.

`install.ps1` does all three. **Run it OUTSIDE Claude Code.**

## ⚠ The wcifs / AppContainer trap (read adom-desktop/CLAUDE.md)

For Claude-spawned tooling, `%LOCALAPPDATA%\Adom Desktop\...` is silently redirected to a per-package
shadow — PowerShell, `Start-Process`, and the Write/Edit tool all hit the shadow, not the real path.
So **from a Claude session, do the bridges-cache copy via WSL2 `cp`** (bypasses wcifs):

```bash
cp -r bridge/* "/c/Users/<user>/AppData/Local/Adom Desktop/bridges-cache/native-browser/"
```

…or via `adom-desktop shell_execute`. The HKCU/HKLM registry writes and the `.bat`/manifest writes
(under this repo) are NOT in the trapped paths and are fine from PowerShell run outside Claude.

## Better long-term: wiki-streamed bridge

adom-desktop already streams bridges from the wiki (`bridge_cache.rs` / `WIKI_STATIC_BASE`). Publishing
`bridge/` as a wiki package lets AD pull + cache it with no manual copy — the preferred delivery once
this stabilizes. See the plan's distribution section.

## update.xml

`update.xml` is the self-hosted `.crx` auto-update manifest the force-install policy points at. Sign
the `.crx` with our own keypair (`.pem`); the extension ID is the hash of its public key, so **reuse
the same key for every update**. Template lands when we cut the first signed `.crx` (Milestone 6).