pi-project-switcher 0.8.0 → 0.8.1

package/README.md

@@ -15,7 +15,7 @@ A [pi coding agent](https://github.com/earendil-works/pi) extension to switch be
   - sets the session display name
   - injects the project path into every agent turn's system prompt, so file operations default to the active project
   - **via the Telegram bridge**: the switch is confirmed in the chat — a short reply with the project, working directory, and session identity, plus buttons (project list, and switch back to the previous project). The confirmation is sent from the new session runtime, so it also works when the switch restores a stored session. No-switch outcomes (already active, cancelled, unknown) are answered in the chat too.
-  - **Telegram transport re-arm**: a session-replacing switch from the Telegram bridge suspends the bridge's polling (pi-telegram stands down on session shutdown and its auto-reconnect declines the handoff because the restored session's cwd differs from the lock's cwd). The switcher therefore re-runs `/telegram-connect` from the new session ~9 s after the switch — but **only** when the session being left provably owned the connected transport: pi-telegram's lock (`~/.pi/agent/tmp/telegram/owners.json`) must name this process with a fresh heartbeat and a cwd matching the old session. Native switches and switches from sessions that didn't own the bot never re-arm. The lock file is only read, never modified.
+  - **Telegram transport re-arm**: a session-replacing switch from the Telegram bridge loses the bridge's transport: pi-telegram stands down on session shutdown, and its reconnect cannot take over the lock across the restored session's different cwd (same-pid locks never go stale; same-process takeover requires matching cwd). The switcher therefore transitions the transport across the switch itself: before the session switch it executes `/telegram-disconnect` (which releases pi-telegram's lock), and after the switch it re-executes `/telegram-connect` from the new session (~3 s delay) — but **only** when the session being left provably owned the connected transport: pi-telegram's lock (`~/.pi/agent/tmp/telegram/owners.json`) must name this process with a fresh heartbeat and a cwd matching the old session. A cancelled switch reconnects immediately. Native switches and switches from sessions that didn't own the bot never touch the transport. The lock file is only read, never modified.
   - **if the project doesn't exist yet**, offers to create the folder and switch to it (confirmation dialog on dialog-capable surfaces; use `/project <name>!` to skip the dialog — e.g. on headless/RPC surfaces). Unsafe names (path segments, `..`, hidden, absolute) are never created.
 - **Session restore** — a machine-local map (`~/.pi/agent/project-switcher-sessions.json`) remembers the most recent session per project. Switching projects returns you to that project's last session; if none exists (or the file is gone), the switch happens in the current session.
 - **Auto-detection** — if pi starts inside `~/dev/<project>`, that project is active automatically

package/index.ts

@@ -356,13 +356,39 @@ function telegramOwnersPath(): string {
 const TELEGRAM_OWNERSHIP_FRESH_MS = 10_000;
 
 /**
- * Delay before re-dispatching /telegram-connect after a session-replacing
- * switch. Must exceed pi-telegram's lock staleness window (8s): the
- * suspended old runtime stops refreshing the heartbeat at session
- * shutdown, and a *stale* lock is the only one the connect handler's
- * non-forced acquire can replace across a cwd mismatch.
+ * Delay before re-dispatching /telegram-connect in the new runtime. The
+ * pre-switch /telegram-disconnect already released the lock synchronously,
+ * so the connect succeeds unconditionally; the short delay only avoids
+ * racing the session-replacement lifecycle observers.
  */
-const TELEGRAM_REARM_DELAY_MS = 9_000;
+const TELEGRAM_REARM_DELAY_MS = 3_000;
+
+/**
+ * Release the Telegram transport from the OLD (owning) runtime, before
+ * the session is replaced. pi's prompt() executes extension commands
+ * synchronously, so when this returns, pi-telegram has stopped polling and
+ * released the lock (deleted the owners.json entry). Only the owning
+ * runtime can release (release() is ownership-guarded), which is exactly
+ * why this must run before ctx.switchSession() — and why the probe must
+ * pass first. Threaded Mode is disabled for this bot, so no confirmation
+ * dialog is raised in the headless daemon.
+ */
+async function releaseTelegramTransportBeforeSwitch(pi: any, source: string): Promise<boolean> {
+  try {
+    await pi.sendUserMessage("/telegram-disconnect", {
+      expandPromptTemplates: true,
+    });
+    return true;
+  } catch (err: any) {
+    try {
+      pi.notify?.(`Telegram release before ${source} switch failed: ${err?.message ?? err}`, "warning");
+    } catch {
+      // Non-fatal: the switch proceeds; a later manual /telegram-connect
+      // still works because we never mutated anything.
+    }
+    return false;
+  }
+}
 
 /**
  * Read-only probe: is the session we are about to leave the live owner of
@@ -412,8 +438,10 @@ function scheduleTelegramRearm(newCtx: any, source: string): void {
     pendingRearmTimer = null;
     try {
       // Command re-dispatch from the FRESH runtime: executes pi-telegram's
-      // connect handler (no agent turn) and re-acquires the now-stale lock,
-      // restarting polling in the new session.
+      // connect handler (no agent turn). The lock was released by the
+      // pre-switch disconnect, so the acquire succeeds unconditionally —
+      // no staleness wait, no takeover dialog (same-pid locks never go
+      // stale, and same-process takeover cannot cross a cwd mismatch).
       await newCtx.sendUserMessage("/telegram-connect", {
         expandPromptTemplates: true,
       });
@@ -686,13 +714,23 @@ export default function (pi: ExtensionAPI) {
       const branchStr = branch ? ` on branch \`${branch}\`` : "";
       // Ownership probe BEFORE the switch (the old session's cwd is only
       // available here): when the session we are leaving is the live owner
-      // of the connected Telegram transport, the new runtime must re-arm
-      // it after the switch (pi-telegram suspends polling on session
-      // shutdown and its auto-start declines the handoff across a cwd
-      // mismatch). The probe failing means we are NOT the owner (another
-      // pi instance, or Telegram was never connected here): re-arm nothing.
+      // of the connected Telegram transport, the transport must be carried
+      // across the replacement: the old runtime releases it now (the only
+      // runtime that CAN — release() is ownership-guarded), and the new
+      // runtime re-arms it in withSession. Without the release, the lock
+      // entry would stay forever active-here (same-pid locks never go
+      // stale) and the connect could never re-acquire across the cwd
+      // change. The probe failing means we are NOT the owner (another pi
+      // instance, or Telegram was never connected here): touch nothing.
       const ownedTelegramTransport =
         isTelegramOrigin && probeTelegramTransportOwnership(ctx.cwd);
+      let releasedTelegramTransport = false;
+      if (ownedTelegramTransport) {
+        // Must run while the old runtime is still current, i.e. before
+        // ctx.switchSession(). Executes /telegram-disconnect synchronously
+        // (pi runs extension commands before any queue/streaming logic).
+        releasedTelegramTransport = await releaseTelegramTransportBeforeSwitch(pi, name);
+      }
       const result = await ctx.switchSession(targetSession, {
         withSession: async (newCtx: any) => {
           // Safety net in case the restored session has no project entry:
@@ -723,11 +761,11 @@ export default function (pi: ExtensionAPI) {
               { deliverAs: "followUp" }
             );
           }
-          if (ownedTelegramTransport) {
-            // Re-arm the Telegram transport from the fresh runtime. Only the
-            // withSession context is touched; the delay lets the old lock
-            // go stale (see TELEGRAM_REARM_DELAY_MS) so the connect
-            // handler's acquire can replace it across the cwd mismatch.
+          if (releasedTelegramTransport) {
+            // Re-arm the Telegram transport from the fresh runtime. The lock
+            // was released by the pre-switch disconnect, so this connect
+            // acquires unconditionally after the short safety delay. Only
+            // the withSession context is touched (see scheduleTelegramRearm).
             scheduleTelegramRearm(newCtx, name);
           }
         },
@@ -738,6 +776,23 @@ export default function (pi: ExtensionAPI) {
         // attempted; an explicit later status/switch overrides it.
         activeProject = previous;
         ctx.ui.notify(`Switch cancelled. Staying on ${previous ?? "no project"}.`, "info");
+        if (releasedTelegramTransport) {
+          // The pre-switch disconnect released the transport for the
+          // replacement that is now NOT happening: reconnect from this
+          // (still-current) runtime so the cancelled switch leaves the
+          // transport in its original state. No lock remains, so the
+          // connect re-acquires unconditionally.
+          try {
+            await pi.sendUserMessage("/telegram-connect", {
+              expandPromptTemplates: true,
+            });
+          } catch (err: any) {
+            ctx.ui.notify(
+              `Telegram reconnect after cancelled switch failed: ${err?.message ?? err}`,
+              "warning"
+            );
+          }
+        }
         if (isTelegramOrigin) {
           await ctx.waitForIdle();
           pi.sendUserMessage(

package/package.json

@@ -1 +1 @@
-{"name": "pi-project-switcher", "version": "0.8.0", "description": "pi coding agent extension: switch between projects under a configurable base directory via /project", "main": "index.ts", "type": "module", "scripts": {"test": "vitest run", "test:watch": "vitest", "typecheck": "tsc --noEmit"}, "keywords": ["pi", "pi-package", "pi-extension", "project", "switcher", "project-switching"], "author": "stefclawd", "license": "MIT", "repository": {"type": "git", "url": "git+https://github.com/stefclawd/pi-project-switcher.git"}, "bugs": {"url": "https://github.com/stefclawd/pi-project-switcher/issues"}, "homepage": "https://github.com/stefclawd/pi-project-switcher#readme", "files": ["index.ts", "README.md", "LICENSE"], "engines": {"node": ">=22.19.0"}, "pi": {"extensions": ["./index.ts"]}, "devDependencies": {"@earendil-works/pi-coding-agent": "^0.85.1", "@types/node": "^24.0.0", "typescript": "^5.7.0", "vitest": "^3.0.0"}}
+{"name": "pi-project-switcher", "version": "0.8.1", "description": "pi coding agent extension: switch between projects under a configurable base directory via /project", "main": "index.ts", "type": "module", "scripts": {"test": "vitest run", "test:watch": "vitest", "typecheck": "tsc --noEmit"}, "keywords": ["pi", "pi-package", "pi-extension", "project", "switcher", "project-switching"], "author": "stefclawd", "license": "MIT", "repository": {"type": "git", "url": "git+https://github.com/stefclawd/pi-project-switcher.git"}, "bugs": {"url": "https://github.com/stefclawd/pi-project-switcher/issues"}, "homepage": "https://github.com/stefclawd/pi-project-switcher#readme", "files": ["index.ts", "README.md", "LICENSE"], "engines": {"node": ">=22.19.0"}, "pi": {"extensions": ["./index.ts"]}, "devDependencies": {"@earendil-works/pi-coding-agent": "^0.85.1", "@types/node": "^24.0.0", "typescript": "^5.7.0", "vitest": "^3.0.0"}}