cursedbelt-server 4.26.0 → 4.26.1

package/dist/server/master-lock/masterLock.d.ts

@@ -257,6 +257,16 @@ export declare class MasterLock {
      * `req` is optional only so a health check can ask without one. Pass it wherever there
      * IS a request: without it the reply carries no account, and a client would read that
      * as "locked" while holding a perfectly good unlock.
+     *
+     * 🔴 With a request, `locked` is THIS CALLER's answer — the one {@link accountFor} gives —
+     * and never the site's. Until 4.26.1 it read {@link unlocked} ("somebody's device is
+     * open"), which the lock page's own script takes as "you are in" and answers with
+     * `location.reload()`; the guard, asking the per-caller question, serves the lock page
+     * again, and the page spins for as long as any other browser stays unlocked — no password
+     * box ever settles. Measured 2026-09-23 on the binary-server inspector: a second Chromium
+     * context reloaded `/__lock/` in a tight loop while `/__lock/status` told it
+     * `"locked": false` with no cookie at all. Without a request it stays the site-wide
+     * health reading, which is all a caller with no request can mean.
      */
     status(req?: Request): MasterLockStatus;
     /**

package/dist/server/master-lock/masterLock.js

@@ -191,6 +191,16 @@ export class MasterLock {
      * `req` is optional only so a health check can ask without one. Pass it wherever there
      * IS a request: without it the reply carries no account, and a client would read that
      * as "locked" while holding a perfectly good unlock.
+     *
+     * 🔴 With a request, `locked` is THIS CALLER's answer — the one {@link accountFor} gives —
+     * and never the site's. Until 4.26.1 it read {@link unlocked} ("somebody's device is
+     * open"), which the lock page's own script takes as "you are in" and answers with
+     * `location.reload()`; the guard, asking the per-caller question, serves the lock page
+     * again, and the page spins for as long as any other browser stays unlocked — no password
+     * box ever settles. Measured 2026-09-23 on the binary-server inspector: a second Chromium
+     * context reloaded `/__lock/` in a tight loop while `/__lock/status` told it
+     * `"locked": false` with no cookie at all. Without a request it stays the site-wide
+     * health reading, which is all a caller with no request can mean.
      */
     status(req) {
         const accountId = req ? this.accountFor(req) : null;
@@ -198,7 +208,7 @@ export class MasterLock {
         return {
             configured: this.configured,
             enrollable: this.awaitingEnrollment,
-            locked: !this.unlocked,
+            locked: req ? accountId === null : !this.unlocked,
             kdf: this.kdf,
             idleMs: this.idleMs,
             remainingMs: this.remainingMs,

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "cursedbelt-server",
-	"version": "4.26.0",
+	"version": "4.26.1",
 	"license": "ISC",
 	"type": "module",
 	"description": "The app-facing Bun/Hono server tier of the cursedbelt split — storage, sharing, activity, guard, sync. React-free; cursedbelt-core below it.",

package/src/server/master-lock/guard.spec.ts

@@ -432,3 +432,26 @@ describe("two locked apps sharing a hostname", () => {
 		expect((await a.guard.handle(xhr("/api/items", onlyB)))?.status).toBe(401);
 	});
 });
+
+describe("🔴 the status route answers for THIS CALLER, never the site", () => {
+	// The lock page's script reloads whenever status says `locked: false`. Read site-wide, one
+	// unlocked browser made every OTHER browser's lock page reload for ever (4.26.1).
+	test("another browser's unlock does not tell a cookieless caller it is in", async () => {
+		const { guard, lock } = build();
+		const cookie = await open(guard);
+		expect(lock.unlocked).toBe(true); // the site IS open, for somebody
+
+		const stranger = await (await guard.handle(xhr(MASTER_LOCK_PATHS.status)))?.json();
+		expect(stranger.locked).toBe(true);
+
+		const owner = await (await guard.handle(xhr(MASTER_LOCK_PATHS.status, cookie)))?.json();
+		expect(owner.locked).toBe(false);
+	});
+
+	test("a request-less health reading is still the site's", async () => {
+		const { guard, lock } = build();
+		expect(lock.status().locked).toBe(true);
+		await open(guard);
+		expect(lock.status().locked).toBe(false);
+	});
+});

package/src/server/master-lock/masterLock.ts

@@ -375,6 +375,16 @@ export class MasterLock {
 	 * `req` is optional only so a health check can ask without one. Pass it wherever there
 	 * IS a request: without it the reply carries no account, and a client would read that
 	 * as "locked" while holding a perfectly good unlock.
+	 *
+	 * 🔴 With a request, `locked` is THIS CALLER's answer — the one {@link accountFor} gives —
+	 * and never the site's. Until 4.26.1 it read {@link unlocked} ("somebody's device is
+	 * open"), which the lock page's own script takes as "you are in" and answers with
+	 * `location.reload()`; the guard, asking the per-caller question, serves the lock page
+	 * again, and the page spins for as long as any other browser stays unlocked — no password
+	 * box ever settles. Measured 2026-09-23 on the binary-server inspector: a second Chromium
+	 * context reloaded `/__lock/` in a tight loop while `/__lock/status` told it
+	 * `"locked": false` with no cookie at all. Without a request it stays the site-wide
+	 * health reading, which is all a caller with no request can mean.
 	 */
 	status(req?: Request): MasterLockStatus {
 		const accountId = req ? this.accountFor(req) : null;
@@ -382,7 +392,7 @@ export class MasterLock {
 		return {
 			configured: this.configured,
 			enrollable: this.awaitingEnrollment,
-			locked: !this.unlocked,
+			locked: req ? accountId === null : !this.unlocked,
 			kdf: this.kdf,
 			idleMs: this.idleMs,
 			remainingMs: this.remainingMs,