| Name | Last updated |
|---|---|
| ab-safety-check.ps1 | 2d ago |
| ad-safety-check.ps1 | 1mo ago |
| install.ps1 | 2d ago |
| README.md | 1d ago |
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).