@valbuild/mcp 0.129.0 → 0.130.0

package/CHANGELOG.md

@@ -1,5 +1,73 @@
 # @valbuild/mcp
 
+## 0.130.0
+
+### Minor Changes
+
+- [#684](https://github.com/valbuild/val/pull/684) [`cab4098`](https://github.com/valbuild/val/commit/cab4098969585977b8d7574e86d66fcb01cb1d75) Thanks [@freekh](https://github.com/freekh)! - A third ValOps mode, for a host that already holds its own source
+
+  EXPERIMENTAL. `fs` mode assumes a working tree it can watch and write; `http`
+  mode assumes Val's content service owns the patch chain and that a commit is a
+  git commit. A host that builds and publishes its own output is neither: it holds
+  the source already, it has nowhere to watch, and its "commit" is a new build.
+
+  Forcing such a host into `fs` mode cost three things, all now fixed: `/stat`
+  long-polled against watchers that could never fire, burning CPU for the whole
+  hold to learn nothing;
+  `/api/val/enable` 500'd; and every read of a `.val.ts` went through a shimmed
+  filesystem when the host could simply hand the source over.
+
+  `ValOpsMemory` takes the source as `sourceFiles`, refuses the local binary
+  members by name — this configuration uses Val's remote files — and answers the
+  history members with the same closed `not-supported-in-fs-mode` error `ValOpsFS`
+  gives, so the History UI degrades the way it already knows how rather than
+  inventing a commit list.
+
+  `getStat` still long-polls -- the hold is what paces the client, and an earlier
+  version that answered immediately turned a 20-second poll into a request every
+  6ms -- but it parks on a SIGNAL rather than a timer. This mode owns its store,
+  so it is told when something changes: no timers while parked, and a patch
+  written by another tab is seen at once rather than up to 250ms later.
+
+  Two seams come with it. `commitPrepared` lets a host take what a save produced
+  instead of a git commit, and `publishOverride` lets a publish be something other
+  than a push. Both are opt-in; an app that sets neither behaves exactly as before.
+
+  The in-memory patch store is explicitly **not durable**. It is behind
+  `ValPatchStore`, so a durable implementation is a swap rather than a rewrite,
+  but as shipped a restart loses unpublished patches.
+
+  **Memory mode authenticates.** `ValOps` gained `requiresAuth` alongside
+  `patchesAreLocal`, because one flag was answering two questions: whether a store
+  auto-saves or publishes (behaviour, reported as `mode` and keyed off by the UI),
+  and whether an unauthenticated request may write (security). With two
+  implementations the answers coincided — `fs` is a developer's own machine where
+  no credential exists, `http` is remote — so `getAuth` was written against
+  `patchesAreLocal` and returned anonymous _success_ for a missing cookie, an
+  invalid JWT, an unparseable payload, or no configured secret.
+
+  Memory mode splits them: its store is local, and it runs deployed. It therefore
+  requires a verified session, like `http` mode. A host that authorises requests
+  before Val sees them can opt out with `unsafelyAllowUnauthenticated`, which is
+  spelled that way on purpose and warns at startup. `fs` mode is unchanged.
+
+  Val's own MCP endpoint refuses memory mode outright. It has the same absence fs
+  mode has — no credential, no backend, every permission check on the far side of
+  one — and unlike fs mode it is meant to run deployed, so the existing
+  "development only" and loopback guards refuse nothing. A host in this mode owns
+  its own trust boundary and can offer the tools through it.
+
+  Internally, the routes' `instanceof ValOpsFS` checks meant "is this a local
+  store" — correct with two implementations and silently wrong with three. They are
+  now `ValOps.patchesAreLocal` at all 17 policy sites.
+
+### Patch Changes
+
+- Updated dependencies [[`cab4098`](https://github.com/valbuild/val/commit/cab4098969585977b8d7574e86d66fcb01cb1d75), [`8425378`](https://github.com/valbuild/val/commit/8425378c315ea46b5d822f1130b633e0449ff1b0), [`cab4098`](https://github.com/valbuild/val/commit/cab4098969585977b8d7574e86d66fcb01cb1d75), [`473a185`](https://github.com/valbuild/val/commit/473a185f70351b44388f3bc1852649e2c1dbe001), [`64f0de3`](https://github.com/valbuild/val/commit/64f0de339b8621cb5a6c422dfe55cae5b2bbe2a0), [`cab4098`](https://github.com/valbuild/val/commit/cab4098969585977b8d7574e86d66fcb01cb1d75)]:
+  - @valbuild/server@0.130.0
+  - @valbuild/core@0.130.0
+  - @valbuild/shared@0.130.0
+
 ## 0.129.0
 
 ### Patch Changes

package/dist/valbuild-mcp.cjs.dev.js

@@ -3365,7 +3365,7 @@ var packageJson = {
 		"./package.json": "./package.json"
 	},
 	types: "dist/valbuild-mcp.cjs.d.ts",
-	version: "0.129.0",
+	version: "0.130.0",
 	scripts: {
 		typecheck: "tsc --noEmit",
 		test: "jest",
@@ -4343,7 +4343,7 @@ function initValMcp(valModules, config, opts) {
 }
 
 /**
- * The two ways this route is dangerous, both refused here.
+ * The three ways this route is dangerous, all refused here.
  *
  * 1. **Local filesystem mode outside development.** In fs mode there is no
  *    credential and no backend: the tools read and write the running process's
@@ -4361,10 +4361,24 @@ function initValMcp(valModules, config, opts) {
  *    needs a credential in fs mode. So a cross-origin `Origin` is refused, and
  *    in fs mode the request must actually be addressed to a loopback host.
  *
+ * 3. **Memory mode, always.** A host that holds its own source has the same
+ *    absence fs mode has -- no credential, no backend, and every permission
+ *    check on the far side of one -- and unlike fs mode it is *meant* to run
+ *    deployed, so "only in development" refuses nothing. Neither does the
+ *    loopback check: there is no localhost to require. So this is refused
+ *    outright rather than narrowed. A host in this mode owns its own trust
+ *    boundary and can offer the tools through it; what it cannot do is let
+ *    Val's own endpoint write content for anyone who can reach the port.
+ *
  * MCP clients are not browsers and send no `Origin`, so the check costs them
  * nothing.
  */
 function refuseUnsafeRequest(request, mode) {
+  if (mode === "memory") {
+    return jsonResponse(403, {
+      error: "Val: the MCP endpoint is disabled. This project is running in memory mode, where the host holds the source and MCP calls would be unauthenticated writes to it. Serve the tools through the host's own authenticated surface instead."
+    });
+  }
   if (mode === "fs" && process.env.NODE_ENV !== "development") {
     return jsonResponse(403, {
       error: "Val: the MCP endpoint is disabled. This project is running in local filesystem mode, where MCP calls are unauthenticated and write directly to the working tree, so it is only served in development. Configure Val for proxy mode to use MCP on a deployed host."

package/dist/valbuild-mcp.cjs.prod.js

@@ -3365,7 +3365,7 @@ var packageJson = {
 		"./package.json": "./package.json"
 	},
 	types: "dist/valbuild-mcp.cjs.d.ts",
-	version: "0.129.0",
+	version: "0.130.0",
 	scripts: {
 		typecheck: "tsc --noEmit",
 		test: "jest",
@@ -4343,7 +4343,7 @@ function initValMcp(valModules, config, opts) {
 }
 
 /**
- * The two ways this route is dangerous, both refused here.
+ * The three ways this route is dangerous, all refused here.
  *
  * 1. **Local filesystem mode outside development.** In fs mode there is no
  *    credential and no backend: the tools read and write the running process's
@@ -4361,10 +4361,24 @@ function initValMcp(valModules, config, opts) {
  *    needs a credential in fs mode. So a cross-origin `Origin` is refused, and
  *    in fs mode the request must actually be addressed to a loopback host.
  *
+ * 3. **Memory mode, always.** A host that holds its own source has the same
+ *    absence fs mode has -- no credential, no backend, and every permission
+ *    check on the far side of one -- and unlike fs mode it is *meant* to run
+ *    deployed, so "only in development" refuses nothing. Neither does the
+ *    loopback check: there is no localhost to require. So this is refused
+ *    outright rather than narrowed. A host in this mode owns its own trust
+ *    boundary and can offer the tools through it; what it cannot do is let
+ *    Val's own endpoint write content for anyone who can reach the port.
+ *
  * MCP clients are not browsers and send no `Origin`, so the check costs them
  * nothing.
  */
 function refuseUnsafeRequest(request, mode) {
+  if (mode === "memory") {
+    return jsonResponse(403, {
+      error: "Val: the MCP endpoint is disabled. This project is running in memory mode, where the host holds the source and MCP calls would be unauthenticated writes to it. Serve the tools through the host's own authenticated surface instead."
+    });
+  }
   if (mode === "fs" &&         "production" !== "development") {
     return jsonResponse(403, {
       error: "Val: the MCP endpoint is disabled. This project is running in local filesystem mode, where MCP calls are unauthenticated and write directly to the working tree, so it is only served in development. Configure Val for proxy mode to use MCP on a deployed host."

package/dist/valbuild-mcp.esm.js

@@ -3356,7 +3356,7 @@ var packageJson = {
 		"./package.json": "./package.json"
 	},
 	types: "dist/valbuild-mcp.cjs.d.ts",
-	version: "0.129.0",
+	version: "0.130.0",
 	scripts: {
 		typecheck: "tsc --noEmit",
 		test: "jest",
@@ -4334,7 +4334,7 @@ function initValMcp(valModules, config, opts) {
 }
 
 /**
- * The two ways this route is dangerous, both refused here.
+ * The three ways this route is dangerous, all refused here.
  *
  * 1. **Local filesystem mode outside development.** In fs mode there is no
  *    credential and no backend: the tools read and write the running process's
@@ -4352,10 +4352,24 @@ function initValMcp(valModules, config, opts) {
  *    needs a credential in fs mode. So a cross-origin `Origin` is refused, and
  *    in fs mode the request must actually be addressed to a loopback host.
  *
+ * 3. **Memory mode, always.** A host that holds its own source has the same
+ *    absence fs mode has -- no credential, no backend, and every permission
+ *    check on the far side of one -- and unlike fs mode it is *meant* to run
+ *    deployed, so "only in development" refuses nothing. Neither does the
+ *    loopback check: there is no localhost to require. So this is refused
+ *    outright rather than narrowed. A host in this mode owns its own trust
+ *    boundary and can offer the tools through it; what it cannot do is let
+ *    Val's own endpoint write content for anyone who can reach the port.
+ *
  * MCP clients are not browsers and send no `Origin`, so the check costs them
  * nothing.
  */
 function refuseUnsafeRequest(request, mode) {
+  if (mode === "memory") {
+    return jsonResponse(403, {
+      error: "Val: the MCP endpoint is disabled. This project is running in memory mode, where the host holds the source and MCP calls would be unauthenticated writes to it. Serve the tools through the host's own authenticated surface instead."
+    });
+  }
   if (mode === "fs" && process.env.NODE_ENV !== "development") {
     return jsonResponse(403, {
       error: "Val: the MCP endpoint is disabled. This project is running in local filesystem mode, where MCP calls are unauthenticated and write directly to the working tree, so it is only served in development. Configure Val for proxy mode to use MCP on a deployed host."

package/package.json

@@ -20,7 +20,7 @@
     "./package.json": "./package.json"
   },
   "types": "dist/valbuild-mcp.cjs.d.ts",
-  "version": "0.129.0",
+  "version": "0.130.0",
   "preconstruct": {
     "entrypoints": [
       "./index.ts",
@@ -31,9 +31,9 @@
   "dependencies": {
     "minimatch": "^10.2.6",
     "zod": "^4.4.3",
-    "@valbuild/server": "0.129.0",
-    "@valbuild/core": "0.129.0",
-    "@valbuild/shared": "0.129.0"
+    "@valbuild/shared": "0.130.0",
+    "@valbuild/server": "0.130.0",
+    "@valbuild/core": "0.130.0"
   },
   "devDependencies": {
     "@prettier/sync": "^0.6.1",