@@ -60,20 +60,24 @@ reports the surface as "not enabled" even though its switch is on:
 sudo apt-get install -y libsecret-tools
 ```
 
-Then start the WebUI so it admits this extension. An unpacked build's identity
-is derived from the directory it was loaded from, so the host has to be told
-which identity it accepts — development mode does not bypass that check, and an
-identity the host does not know is refused:
+Then start the WebUI. An unpacked build's identity is derived from the
+directory it was loaded from, so it is different on every machine — and the
+host does not need to be told what it is. The host learns the identity from
+the extension itself, once the extension has proved the installation key, and
+remembers it:
 
 ```bash
-MAVIS_BROWSER_EDGE_EXTENSION_IDS=<extension-id> pnpm --filter @mavis/webui dev:server
+pnpm --filter @mavis/webui dev:server
 ```
 
-The extension's options page shows its own id and the exact setting line to
-copy, so the id never has to be read out of the browser's extension manager.
-The packaged WebUI entry reads the **store** allowlist instead
-(`MAVIS_BROWSER_STORE_EDGE_EXTENSION_IDS`), and a locally loaded build is not
-on it — a released package admits the published extension on its own.
+Nothing is configured on the host side, and nothing has to be found out first:
+the id is on the extension's own options page, together with the setting a
+host that pins its extensions would need.
+
+The **packaged** WebUI entry is stricter, on purpose. It admits the published
+extension — the one the store issued — and refuses a locally loaded build
+unless that build's identity is named in the store allowlist
+(`MAVIS_BROWSER_STORE_EDGE_EXTENSION_IDS`).
 
 Then point the extension at the WebUI host. The extension cannot learn the
 host's address by itself, so an absent origin is reported rather than replaced
@@ -97,10 +101,10 @@ options*:
   the client dials with (a loopback `http:` address, with no path);
 - the **installation key** from the WebUI's Settings page, which is
   write-only: the page shows a fingerprint afterwards and never the key;
-- the **extension id** and the **development host setting** it belongs in,
-  which the page derives from the build it is: a published build says that the
-  released WebUI package already admits it, and a local build says which
-  variable has to carry its id.
+- the **extension id** and the **host setting** it belongs in, which the page
+  derives from the build it is. The page also says that there is nothing to
+  set on the host side: a released package admits the published extension, and
+  a development host learns this extension from the proof.
 
 Saving either one wakes the worker, which re-reads the configuration and
 pairs with the host.
 
@@ -76,7 +76,7 @@ <h2>This extension</h2>
       <button id="copy-extension-id" type="button">Copy</button>
     </div>
     <div class="row stacked">
-      <span class="label">Development host setting</span>
+      <span class="label">Host setting</span>
       <input id="host-allowlist" class="value" type="text" readonly spellcheck="false" />
       <button id="copy-host-allowlist" type="button">Copy</button>
     </div>
 
@@ -126,8 +126,8 @@ async function renderIdentity(): Promise<void> {
       : "This is a local build. Its identity comes from the folder it was loaded from, so it differs on every machine.";
   identityNote.textContent =
     kind === "published"
-      ? "The released WebUI package already admits this extension, so there is nothing to set on the host side. The setting below is only for a development WebUI."
-      : "A development WebUI admits only the extensions you name, so start it with the setting below.";
+      ? "Nothing to set on the host side. A released WebUI package admits the published extension, and a development WebUI learns this extension the first time it proves the installation key."
+      : "Nothing to set on the host side. A development WebUI learns this extension the first time it proves the installation key.";
 }
 
 /** Put a value on the clipboard, or say that the clipboard was not there. */
 
@@ -480,3 +480,37 @@ id it admits. That configuration is now visible where the id is: the
 extension's options page shows its own id and the exact setting line that
 carries it, so a person no longer has to read the id out of the browser's
 extension manager to satisfy the host.
+
+### A11 — A development host learns the identity instead of being told it
+
+A10 settled the published identity: it is a constant of the release, so it is
+baked into the package and the person who installs it configures nothing. The
+development host had the same defect for a different reason, and A6 recorded
+it as a configuration value: an unpacked build's id is derived from the
+directory it was loaded from, so it differs on every machine and every path,
+and asking the person to name it was asking for something they cannot know.
+
+So the development host learns the identity instead, and it learns it from a
+proof rather than from a claim:
+
+- The upgrade gate admits an identity the host does not know. This widens who
+  may **try** the handshake, not who may **act**: the peer still has to
+  answer the surface's challenge with the installation key, and A2's
+  proof-first order still holds — a peer that proves nothing is refused and
+  receives no credential.
+- When the peer proves the installation key, or a credential this host already
+  issued, the host records the identity under
+  `<dataDir>/browser-bridge/trusted-extensions.json` and admits it from then
+  on. The file holds identities, not secrets; it is written atomically and
+  owner-only, and a file that cannot be read reads as "nothing is trusted
+  yet", which costs the extension one more proof and no secret.
+- The identity is still per surface, and the peer's own `hello` still says
+  which browser it is on. A5 stands: the name selects which secret to check
+  against, never the identity to believe.
+
+A **packaged** host learns nothing. Its published identity is exact, and a
+packaged host that admitted unknown origins would stop being the published
+extension — which is the whole of A6 and A10.
+
+The development allowlist variables keep working, and add to what the host has
+learned rather than replacing it. They are no longer required for anything.
@@ -65,7 +65,7 @@ and it is the current state of both composition roots:
 
 | Entry point | Line | `dev` | Bridge allowlist |
 | --- | --- | --- | --- |
-| `scripts/run-webui-server.mjs` | 67 | `dev: true` | development — `MAVIS_BROWSER_EDGE_EXTENSION_IDS`, `MAVIS_BROWSER_CHROME_EXTENSION_IDS` |
+| `scripts/run-webui-server.mjs` | 74 | `dev: true` | development — the identities it has learned, plus `MAVIS_BROWSER_EDGE_EXTENSION_IDS`, `MAVIS_BROWSER_CHROME_EXTENSION_IDS` |
 | `release/webui-npm/bin/mcode-webui.mjs` | 93 | `dev: true` | **store** — the published identity the package was built for, plus `MAVIS_BROWSER_STORE_EDGE_EXTENSION_IDS`, `MAVIS_BROWSER_STORE_CHROME_EXTENSION_IDS` |
 
 So on a packaged WebUI today, the generic path already accepts any upgrade that passes the loopback
@@ -96,6 +96,35 @@ requires no extension id, no environment variable and no restart with a hand-wri
 store allowlist variables remain for a self-hosted store build, and they add to the published
 identity rather than replacing it.
 
+## The development host learns the identity it is given
+
+The same reasoning applies to a development host, and for a stronger reason. An unpacked build's id
+is derived from the directory it was loaded from, so it is **different on every machine and every
+path**: there is no constant to bake in, and a name the person has to go and look up is a name they
+will get wrong. So the development host does not ask for one either.
+
+It learns the identity from the extension, and only from a proof:
+
+- The upgrade gate admits an identity the host does not know. This widens **who may try**, not
+  **who may act**: the peer still has to answer the surface's challenge with the installation key,
+  and a peer that cannot is refused and receives no credential.
+- When the peer proves the installation key — or a credential this host already issued — the host
+  records the identity under `<dataDir>/browser-bridge/trusted-extensions.json` and admits it from
+  then on. The file is written atomically and owner-only, and a file that cannot be read reads as
+  "nothing is trusted yet", which costs the extension one more proof and no secret.
+- The identities are per surface, and the peer's own `hello` still says which browser it is on. The
+  name selects **which secret to check against**, never the identity to believe (ADR 0019, A5).
+
+A **packaged** host does not learn anything: its published identity is exact, and a packaged host
+that admitted unknown origins would stop being the published extension. The development
+allowlist variables still work on a development host, and they add to what it has learned rather
+than replacing it.
+
+The cost of the wider upgrade gate is a peer that connects and then goes quiet: it would hold a
+challenge unanswered. Each pairing therefore caps how many challenges it will have outstanding at
+once (`MAX_OUTSTANDING_CHALLENGES`), and the hello deadline closes the sockets that never introduce
+themselves.
+
 **`implemented`: the bridge admission path never reads `dev`.** The pairing proof is verified
 unconditionally, and the browser switch is checked unconditionally. `admission.ts:135` holds an
 explicit no-op `if (context.dev)` branch whose only purpose is to make the absence of a bypass
 
@@ -108,18 +108,23 @@ store's browser** — the Chrome Web Store build in Chrome, the Edge Add-ons bui
    the id named only in `MAVIS_BROWSER_CHROME_EXTENSION_IDS`, refuses it. A packaged host that fell
    back to the development allowlist would admit whatever unpacked extension happened to be present,
    which is the identity nobody can rely on.
+5. **A development host needs to be told nothing.** A development host started with no allowlist at
+   all pairs with the extension anyway: the host learns the identity from the extension that proves
+   the installation key, and remembers it. The case runs against a real Edge and a real Chromium.
 
 The **installed package** is checked too, and not by a bridge the test built. The package
-verification starts the real `mcode-webui` from the installed archive, configures it with **both**
-allowlists, and shows that the store identity is admitted on its `/browser-bridge` path while the
+verification builds the package with the store's public key, starts the real `mcode-webui` from the
+installed archive, and shows that the **published** identity is admitted on its `/browser-bridge`
+path with **nothing configured for it** — the package carries that identity, because it is a
+constant of the release. The identity the environment names is admitted alongside it, and the
 development identity is refused. That is the shipped process, running the shipped configuration.
 
 The two entries are configured apart, in the source:
 
-| Entry | File | Allowlist it reads |
+| Entry | File | Identities it admits |
 | --- | --- | --- |
-| Development | `scripts/run-webui-server.mjs` | `MAVIS_BROWSER_EDGE_EXTENSION_IDS`, `MAVIS_BROWSER_CHROME_EXTENSION_IDS` |
-| **Packaged** | `release/webui-npm/bin/mcode-webui.mjs` | `MAVIS_BROWSER_STORE_EDGE_EXTENSION_IDS`, `MAVIS_BROWSER_STORE_CHROME_EXTENSION_IDS` |
+| Development | `scripts/run-webui-server.mjs` | the ones it has learned, plus `MAVIS_BROWSER_EDGE_EXTENSION_IDS`, `MAVIS_BROWSER_CHROME_EXTENSION_IDS` |
+| **Packaged** | `release/webui-npm/bin/mcode-webui.mjs` | the published identity it was built for, plus `MAVIS_BROWSER_STORE_EDGE_EXTENSION_IDS`, `MAVIS_BROWSER_STORE_CHROME_EXTENSION_IDS` |
 
 The packaged entry passes `packaged: true` to the bridge; the development entry does not.
 
 
@@ -70,6 +70,21 @@ export interface BrowserBridgeAdmissionContext {
    * across all the pairings; tests can substitute a custom matcher.
    */
   readonly isExtensionOrigin?: (origin: string) => string | undefined;
+  /**
+   * Whether an extension identity the host does not know may still attempt
+   * a handshake.
+   *
+   * A development host says yes. An unpacked build's id is derived from the
+   * folder it was loaded from, so it differs on every machine, and asking the
+   * person to name it is asking for something they cannot know. The identity
+   * is learned only after the extension proves the surface's installation
+   * key, so this widens who may *try*, not who may *act*: a peer that cannot
+   * prove the key is refused and receives no credential.
+   *
+   * A packaged host says no. The published identity is exact, and admitting
+   * unknown origins would stop being the published extension.
+   */
+  readonly learnUnknownIdentities?: boolean;
 }
 
 /**
@@ -127,7 +142,12 @@ export function admitBrowserBridgeUpgrade(
   const admitted = [...context.pairings.values()].some((pairing) =>
     pairing.admitsExtensionId(extensionId),
   );
-  if (!admitted) {
+  // A host that learns identities lets an unknown one through this gate, and
+  // no further: the peer still has to prove the installation key before it
+  // is given anything. The gate is a pre-filter (ADR 0019, A2), and this is
+  // the development host saying that the pre-filter cannot be a name the
+  // person has to look up.
+  if (!admitted && !context.learnUnknownIdentities) {
     return reject(socket, 403, "Forbidden Origin");
   }
   // Dev does NOT bypass. The header is on the upgrade so a future wiring
 
@@ -55,6 +55,7 @@ export {
 
 export {
   BrowserBridgePairing,
+  PairingChallengeLimitError,
   PairingSwitchedOffError,
   type BrowserBridgePairingMetadata,
   type BrowserBridgePairingOptions,
@@ -121,6 +122,14 @@ export {
   type BrowserBridgeDispatch,
 } from "./registry.js";
 
+export {
+  createFileTrustedExtensionStore,
+  createInMemoryTrustedExtensionStore,
+  isExtensionId,
+  trustedExtensionsFile,
+  type TrustedExtensionStore,
+} from "./trusted-extensions.js";
+
 export {
   BrowserBridgeServer,
   WebuiBridgeOperationError,
 
@@ -38,6 +38,18 @@ import {
 
 const NONCE_BYTES = 32;
 
+/**
+ * How many challenges one pairing will have outstanding at once.
+ *
+ * A challenge is a nonce the host has issued and the peer has not answered.
+ * A peer that connects and then goes quiet holds one, and a host that lets
+ * identities be learned has to assume that some of those peers are not the
+ * extension anyone expected. The cap bounds what such a peer can hold, and
+ * the hello deadline closes the sockets that never even introduced
+ * themselves.
+ */
+const MAX_OUTSTANDING_CHALLENGES = 16;
+
 /** The non-secret metadata for a credential, suitable for surfacing in the UI. */
 export interface BrowserBridgePairingMetadata {
   readonly keyId: string;
@@ -228,6 +240,13 @@ export class BrowserBridgePairing {
         `cannot issue challenge for "${this.surface}"`,
       );
     }
+    // The cap comes before the nonce is made, so a refused peer costs no
+    // entropy and leaves no trace to clean up.
+    if (this.outstandingNonces.size >= MAX_OUTSTANDING_CHALLENGES) {
+      throw new PairingChallengeLimitError(
+        `browser bridge for "${this.surface}" has too many unanswered challenges`,
+      );
+    }
     const nonceBytes = this.randomBytesSource(NONCE_BYTES);
     const nonce = bufferToBase64Url(nonceBytes);
     this.outstandingNonces.add(nonce);
@@ -617,6 +636,22 @@ export class PairingSwitchedOffError extends Error {
   }
 }
 
+/**
+ * A typed signal that the pairing refuses because too many challenges are
+ * already unanswered.
+ *
+ * A host that learns identities lets unknown extensions attempt a handshake,
+ * so it has to be able to say no to a peer that keeps taking challenges and
+ * answering none. The peer is closed rather than served, and the reason is
+ * specific so that it is not mistaken for a credential problem.
+ */
+export class PairingChallengeLimitError extends Error {
+  constructor(message: string) {
+    super(message);
+    this.name = "PairingChallengeLimitError";
+  }
+}
+
 /** Encode bytes as base64url with no padding — the challenge's nonce format. */
 function bufferToBase64Url(bytes: Uint8Array): string {
   return Buffer.from(bytes)