install/
Three registrations on a managed Windows machine (golden image / ah / winvm):
- Bridge → ab
bridges-cache—bridge/copied to%LOCALAPPDATA%\Adom Bridge\bridges-cache\ native-browser\; Bridge's registry auto-discovers it and routesnbrowser_*to it. - Native-messaging host (HKCU, no UAC) — render
host-manifest.jsonfrom the template (absolutenative-host.batpath + the extension ID inallowed_origins) and register it underHKCU\Software\<vendor>\NativeMessagingHosts\inc.adom.native_browserfor 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-bridge/CLAUDE.md)
For Claude-spawned tooling, %LOCALAPPDATA%\Adom Bridge\... 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 Bridge/bridges-cache/native-browser/"
…or via adom-bridge-cli 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
Bridge already streams bridges from the wiki (bridge_cache.rs / WIKI_STATIC_BASE). Publishing
bridge/ as a wiki package lets ab 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 / ah / winvm):
1. **Bridge → ab `bridges-cache`** — `bridge/` copied to `%LOCALAPPDATA%\Adom Bridge\bridges-cache\
native-browser\`; Bridge'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-bridge/CLAUDE.md)
For Claude-spawned tooling, `%LOCALAPPDATA%\Adom Bridge\...` 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 Bridge/bridges-cache/native-browser/"
```
…or via `adom-bridge-cli 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
Bridge already streams bridges from the wiki (`bridge_cache.rs` / `WIKI_STATIC_BASE`). Publishing
`bridge/` as a wiki package lets ab 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).