# 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).