agent-comms 9.0.12 → 9.0.13

package/.claude-plugin/marketplace.json

@@ -15,7 +15,7 @@
         "source": "url",
         "url": "https://github.com/ExaDev/agent-comms.git"
       },
-      "version": "9.0.12"
+      "version": "9.0.13"
     }
   ]
 }

package/.claude-plugin/plugin.json

@@ -17,5 +17,5 @@
   },
   "name": "agent-comms",
   "repository": "https://github.com/ExaDev/agent-comms",
-  "version": "9.0.12"
+  "version": "9.0.13"
 }

package/README.md

@@ -323,6 +323,8 @@ Any bridge that starts a web server (`npx agent-comms chat`, or any other comman
 
 A bridge's web server binds the first free TCP port from 19877 to 19886, so several bridges on one machine each get a port of their own in that range, and takes a port the operating system picks only when all ten are taken. The hosted dashboard looks for a bridge on those same ports, which is how it finds one without being told a port. The address a bridge prints, and the `web_url` action returns, is the port it actually holds.
 
+The dashboard page carries a content security policy (a meta tag, since a static host sets no headers): it denies everything by default, allows script only from its own origin, and allows connections only to its own origin and to `127.0.0.1` and `localhost`. The policy binds the page. The shared worker that holds the bridge connection takes its policy from its own script's response headers, which a static host does not set, so the worker is not bound by it; and a policy in a meta tag cannot forbid the page being framed, which needs a response header. Its service worker answers a page navigation from the network while the host is reachable and from its cache only when the host cannot be reached, so a redirect the host answers is always followed. The origin the hosted dashboard is served from is defined once, in `src/bridges/user/web/hosted-dashboard.ts`.
+
 Two independent transports sit inside that dashboard, both built on [oRPC](https://orpc.unnoq.com/), a contract-first RPC layer with Zod-validated inputs and outputs and native support for streaming procedures:
 
 - **Worker ↔ server**, over a real WebSocket at `/ws/mesh`. The worker is an oRPC client here, calling the same contract procedures the REST API exposes, plus a `subscribeEvents` procedure that streams mesh events as they happen.