ofw-mcp 2.15.1 → 2.16.0

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "OurFamilyWizard tools for Claude Code",
-    "version": "2.15.1"
+    "version": "2.16.0"
   },
   "plugins": [
     {
@@ -14,7 +14,7 @@
       "displayName": "OurFamilyWizard",
       "source": "./",
       "description": "OurFamilyWizard co-parenting tools for Claude — messages, calendar, expenses, and journal via MCP",
-      "version": "2.15.1",
+      "version": "2.16.0",
       "author": {
         "name": "Chris Chall"
       },

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "ofw",
   "displayName": "OurFamilyWizard",
-  "version": "2.15.1",
+  "version": "2.16.0",
   "description": "OurFamilyWizard co-parenting tools for Claude — messages, calendar, expenses, and journal via MCP",
   "author": {
     "name": "Chris Chall"

package/README.md

@@ -251,6 +251,10 @@ By default nothing changes: reads behave exactly as they always have. Two contro
 
 Calendar events sit between the two message tiers: they have no draft stage (a created event is immediately visible on the shared record), but unlike a sent message they are reversible — an event can be edited or deleted afterward. If you run in `drafts` mode but are comfortable with direct calendar writes, set `OFW_CALENDAR_WRITES=true` to additionally register `ofw_create_event`, `ofw_update_event`, and `ofw_delete_event`. The flag is redundant in `all` mode and never overrides `none`.
 
+### Egress allowlist
+
+Every outbound request passes its constructed URL through a host check before `fetch` — the server refuses to contact any host other than `ofw.ourfamilywizard.com`. Today it always passes, and that is the point: it makes "this server only ever talks to OFW" a structural invariant rather than a code-review promise, so a later refactor or a compromised dependency that pointed a request elsewhere throws instead of carrying your bearer token or messages off-host. It is a pre-flight check on the URL we build, not a redirect-following egress filter.
+
 ## Troubleshooting
 
 **"0 messages"** — Claude may have read the notification counts rather than the actual messages. Ask explicitly: *"List the messages in my OFW inbox"* or *"Use ofw_list_message_folders then ofw_list_messages"*.
@@ -271,6 +275,7 @@ Calendar events sit between the two message tiers: they have no draft stage (a c
 - They are passed to the server as environment variables and never logged
 - The server authenticates with OFW using the same login flow as the web app
 - Use a strong, unique OFW password
+- Outbound requests are host-allowlisted to `ofw.ourfamilywizard.com` (see [Egress allowlist](#egress-allowlist))
 
 ## Development
 

package/dist/auth-password.js

@@ -9,10 +9,12 @@
 // This file exists as a standalone helper (not a method on `OFWClient`) so
 // `resolveAuth()` in `./auth.ts` can call it without a Client instance, and
 // so tests can mock it at the module boundary.
-import { BASE_URL, OFW_PROTOCOL_HEADERS, OFW_TOKEN_TTL_MS } from './protocol.js';
+import { BASE_URL, OFW_PROTOCOL_HEADERS, OFW_TOKEN_TTL_MS, assertOfwUrl } from './protocol.js';
 export async function loginWithPassword(username, password) {
     // Step 1: get a SESSION cookie (Spring Security refuses the POST without it).
-    const initResponse = await fetch(`${BASE_URL}/ofw/login.form`, {
+    const initUrl = `${BASE_URL}/ofw/login.form`;
+    assertOfwUrl(initUrl);
+    const initResponse = await fetch(initUrl, {
         headers: { ...OFW_PROTOCOL_HEADERS },
         redirect: 'manual',
     });
@@ -24,7 +26,9 @@ export async function loginWithPassword(username, password) {
         .map((c) => c.split(';')[0])
         .join('; ');
     // Step 2: submit the form.
-    const response = await fetch(`${BASE_URL}/ofw/login`, {
+    const loginUrl = `${BASE_URL}/ofw/login`;
+    assertOfwUrl(loginUrl);
+    const response = await fetch(loginUrl, {
         method: 'POST',
         headers: {
             ...OFW_PROTOCOL_HEADERS,