@pify/swarm 0.7.2 → 0.7.3

package/extensions/swarm.ts

@@ -25,6 +25,7 @@ import { Text } from "@earendil-works/pi-tui";
 import { Type } from "typebox";
 
 import { BUILTIN_AGENTS } from "../src/builtin.ts";
+import { withUiLock } from "../src/ui-lock.ts";
 import {
   consentQuestion,
   decideConsent,
@@ -542,9 +543,11 @@ export default function swarm(pi: ExtensionAPI) {
     });
     if (verdict !== "ask") return verdict === "allow";
 
-    const approved = await ctx.ui.confirm(
-      "Load this project's agent definitions?",
-      consentQuestion("its own agent definitions, which override the builtins of the same name", dir),
+    const approved = await withUiLock(() =>
+      ctx.ui.confirm(
+        "Load this project's agent definitions?",
+        consentQuestion("its own agent definitions, which override the builtins of the same name", dir),
+      ),
     );
     try {
       writeFileSync(file, `${JSON.stringify(writeConsent(store, ctx.cwd, "agents", approved), null, 2)}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pify/swarm",
-  "version": "0.7.2",
+  "version": "0.7.3",
   "description": "Coordinate multiple pi agents in parallel: swarm_run fan-out with per-item auto-routing, concurrency queue, aggregated reports",
   "keywords": [
     "pi-package",

package/src/ui-lock.ts

@@ -0,0 +1,52 @@
+/**
+ * One dialog at a time, across every @pify extension in the process.
+ *
+ * pi's interactive host has no queue for extension dialogs: opening a second
+ * `ui.select`/`ui.confirm`/`ui.input` while one is already up displaces the
+ * first component without ever calling its cancel callback, so the first
+ * dialog's promise never settles — the turn hangs (measured in pi's
+ * interactive-mode source: showExtensionSelector clears and replaces the
+ * active selector, and only hideExtensionSelector disposes it). This is a
+ * real collision in this suite: ask-question opens a questionnaire while a
+ * consent prompt (memory/swarm/workflow/subagent) or a yolo confirm can fire
+ * in the same turn, and parallel tool calls make that ordinary.
+ *
+ * The fix is to never let a second dialog open until the first has closed.
+ * A timeout would not help — releasing the lock while the dialog is still on
+ * screen just re-creates the collision — so this is a plain FIFO mutex with
+ * no deadline. It is deliberately keyed on a cross-realm `Symbol.for`, so all
+ * eighteen packages share ONE queue even though each ships its own copy of
+ * this file: the state lives on `globalThis`, not in any one module.
+ *
+ * Vendored per package, like consent.ts, so the suite keeps zero runtime
+ * dependencies.
+ */
+
+const LOCK_KEY = Symbol.for("pify.ui-lock.tail");
+
+interface LockGlobal {
+  [LOCK_KEY]?: Promise<unknown>;
+}
+
+/**
+ * Run `fn` only once every dialog queued before it has finished, and hold the
+ * queue until `fn` settles. A rejection in an earlier holder never wedges the
+ * chain — the next waiter proceeds regardless.
+ */
+export async function withUiLock<T>(fn: () => Promise<T>): Promise<T> {
+  const g = globalThis as unknown as LockGlobal;
+  const prev = g[LOCK_KEY] ?? Promise.resolve();
+
+  let release!: () => void;
+  const mine = new Promise<void>((resolve) => {
+    release = resolve;
+  });
+  g[LOCK_KEY] = prev.then(() => mine);
+
+  await prev.catch(() => {});
+  try {
+    return await fn();
+  } finally {
+    release();
+  }
+}