patchcord 0.5.2 → 0.5.4

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "patchcord",
   "description": "Cross-machine agent messaging with push delivery. Messages from other agents arrive as native channel notifications.",
-  "version": "0.5.2",
+  "version": "0.5.4",
   "author": {
     "name": "ppravdin"
   },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "patchcord",
-  "version": "0.5.2",
+  "version": "0.5.4",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "author": "ppravdin",
   "license": "MIT",

package/scripts/lib/ws.mjs

@@ -68,7 +68,7 @@ export function connect(urlStr, { headers = {} } = {}) {
   socket.on("close", () => {
     if (!closed) {
       closed = true;
-      emitter.emit("close");
+      emitter.emit("close", { code: null, reason: "socket-ended" });
     }
   });
 
@@ -115,8 +115,16 @@ export function connect(urlStr, { headers = {} } = {}) {
       if (opcode === 0x1) {
         emitter.emit("message", payload.toString("utf8"));
       } else if (opcode === 0x8) {
-        // close frame
-        emitter.emit("close");
+        // close frame — parse code/reason for diagnostics
+        let code = null;
+        let reason = "";
+        if (payload.length >= 2) {
+          code = payload.readUInt16BE(0);
+          if (payload.length > 2) {
+            reason = payload.slice(2).toString("utf8");
+          }
+        }
+        emitter.emit("close", { code, reason });
         closed = true;
         try {
           socket.write(encodeFrame(0x8, closePayload(1000, ""), true));

package/scripts/subscribe.mjs

@@ -17,6 +17,17 @@ const JWT_REFRESH_SAFETY_MARGIN_SEC = 120;
 const HEARTBEAT_INTERVAL_MS = 25_000;
 const RECONNECT_BACKOFF_MS = [1000, 2000, 4000, 8000, 15_000, 30_000];
 
+// Guarantee a terminal stderr line on any unhandled failure so the agent
+// reading Monitor's output file always sees WHY the process died.
+process.on("uncaughtException", (err) => {
+  process.stderr.write(`subscribe: fatal: uncaught: ${err?.stack || err?.message || err}\n`);
+  process.exit(1);
+});
+process.on("unhandledRejection", (err) => {
+  process.stderr.write(`subscribe: fatal: unhandled rejection: ${err?.stack || err?.message || err}\n`);
+  process.exit(1);
+});
+
 function die(msg, code = 1) {
   process.stderr.write(msg + "\n");
   process.exit(code);
@@ -235,14 +246,29 @@ function runOnce(ticket, baseUrl, token, refreshTicket) {
         } catch (_) {}
       }, HEARTBEAT_INTERVAL_MS);
 
-      const refreshIn = Math.max(
-        (ticket.jwt_expires_in - JWT_REFRESH_SAFETY_MARGIN_SEC) * 1000,
-        30_000
-      );
-      refreshTimer = setTimeout(async () => {
+      const scheduleRefresh = (ttlSec) => {
+        const refreshIn = Math.max((ttlSec - JWT_REFRESH_SAFETY_MARGIN_SEC) * 1000, 30_000);
+        refreshTimer = setTimeout(doRefresh, refreshIn);
+      };
+
+      const doRefresh = async () => {
+        if (settled) return;
         try {
           const fresh = await refreshTicket();
           currentJwt = fresh.jwt;
+          // Socket-level auth update (phoenix topic) — what Supabase
+          // actually uses for the connection's own JWT expiry check.
+          // Without this, the server closes the socket at the original
+          // JWT's exp regardless of per-channel updates.
+          ws.send(
+            JSON.stringify({
+              topic: "phoenix",
+              event: "access_token",
+              payload: { access_token: currentJwt },
+              ref: String(ref++),
+            })
+          );
+          // Channel-level updates — matches supabase-js's setAuth() pattern.
           for (const topic of fresh.topics) {
             ws.send(
               JSON.stringify({
@@ -254,11 +280,17 @@ function runOnce(ticket, baseUrl, token, refreshTicket) {
             );
           }
           process.stderr.write("subscribe: token refreshed\n");
+          scheduleRefresh(fresh.jwt_expires_in);
         } catch (e) {
-          process.stderr.write(`subscribe: token refresh failed: ${e.message}\n`);
-          done(e);
+          // Transient network/server error — do NOT close the live
+          // connection. The current JWT is still valid for ~2 more min
+          // (JWT_REFRESH_SAFETY_MARGIN_SEC). Retry sooner.
+          process.stderr.write(`subscribe: token refresh failed, retrying in 30s: ${e.message}\n`);
+          refreshTimer = setTimeout(doRefresh, 30_000);
         }
-      }, refreshIn);
+      };
+
+      scheduleRefresh(ticket.jwt_expires_in);
     });
 
     ws.on("message", (raw) => {
@@ -286,8 +318,10 @@ function runOnce(ticket, baseUrl, token, refreshTicket) {
       done(err);
     });
 
-    ws.on("close", () => {
-      process.stderr.write("subscribe: ws closed\n");
+    ws.on("close", (info) => {
+      const codeStr = info?.code != null ? `code=${info.code}` : "code=none";
+      const reasonStr = info?.reason ? ` reason=${JSON.stringify(info.reason)}` : "";
+      process.stderr.write(`subscribe: ws closed (${codeStr}${reasonStr})\n`);
       done();
     });
   });

package/skills/subscribe/SKILL.md

@@ -68,19 +68,19 @@ then the script is at
      description: "patchcord realtime listener (<agent>@<ns>)",
      persistent: true,
      timeout_ms: 3600000,
-     command: "exec node \"<absolute-path-to-subscribe.mjs>\" 2>&1 | grep --line-buffered '^PATCHCORD:'"
+     command: "exec node \"<absolute-path-to-subscribe.mjs>\""
    )
    ```
-   The filter is deliberately narrow: **only** `PATCHCORD:` lines
-   (actual message arrivals) become notifications. Everything else the
-   script writes — `connected`, `token refreshed`, `cwd=...`,
-   `agent=...`, `reconnecting in Nms` — is plumbing the user doesn't
-   need to see. Those lines still land in Monitor's output file, so you
-   can Read them on demand if something looks off.
+   No `2>&1`, no grep filter. By construction the script only writes
+   `PATCHCORD: ...` lines to stdout. Everything else — `connected`,
+   `token refreshed`, startup diagnostics, errors — goes to stderr,
+   which Monitor captures into its output file but does NOT fire as
+   notifications. So there's nothing to filter and no way to get the
+   filter wrong.
 
    Crash detection is handled automatically by Monitor itself: when the
-   `node` process exits, you get a built-in "stream ended" task
-   notification with the exit code. No filter needed for that.
+   process exits, Monitor emits a built-in "stream ended" task
+   notification with the output file path and exit code.
 
 6. **Tell the user one short line:**
    "Patchcord listener active — I'll pick up new messages as they arrive."
@@ -103,25 +103,45 @@ There is no `/patchcord:unsubscribe` command. Tell the user either:
 - Run `kill $(cat /tmp/patchcord_subscribe_<namespace>_<agent>.pid)` in
   a terminal.
 
-# If the Monitor stream ends
+# If the Monitor stream ends — STRICT PROTOCOL
 
-That means the subscribe process exited. Before telling the user
-anything, Read the Monitor output file (the path is in the stream-end
-task notification) to see the last stderr lines. The concrete failure
-strings:
+The stream-end task notification includes the path to Monitor's output
+file. Do exactly this, in this order:
+
+1. Read that output file using the Read tool.
+2. Look at the last ~15 lines for a line matching one of the known
+   failure strings below. There will always be at least one terminal
+   error line — the script's error handlers guarantee it.
+3. Report the specific cause to the user in one short sentence.
+4. STOP.
+
+**Forbidden on failure — do not do any of these:**
+- Do NOT run `pgrep`, `ps`, `kill`, `pkill`, `killall`, or any command
+  that targets PIDs or process names.
+- Do NOT modify, delete, or write to the pidfile yourself. The script
+  manages it; it's already cleaned up by the time Monitor emits the
+  stream-end event.
+- Do NOT spawn another Monitor or another `node subscribe.mjs`. One
+  failure means something is wrong with the config or environment;
+  respawning will not fix it and will make things worse.
+- Do NOT search for orphaned processes or try to "clean up" state.
+
+Concrete failure strings you may see and what they mean:
 
 - `no .mcp.json in <cwd>` — session is not in a patchcord project dir.
-- `token rejected (HTTP 401|403)` — bearer in `.mcp.json` is bad;
-  regenerate from the dashboard.
-- `server not configured for realtime` — server hasn't had
-  `SUPABASE_JWT_SECRET` / `SUPABASE_ANON_KEY` set. Self-hosted without
-  Supabase does not support this feature yet.
-- `namespace not owned` — the token's namespace lost its owner row;
-  regenerate from the dashboard.
-- `already running (pid N)` (exit code 2) — pidfile guard tripped.
-  Another subscribe is active. Report and stop.
-
-Report the specific cause to the user, do not loop or retry. If the
-process exited cleanly after many successful reconnects with no error
-line, that's either a session close or the user killed it — no action
-needed.
+  Tell the user which directory to `cd` into.
+- `ticket: token rejected (HTTP 401|403)` — bearer in `.mcp.json` is
+  bad; regenerate from the dashboard.
+- `ticket: server not configured for realtime` — the patchcord server
+  hasn't had `SUPABASE_JWT_SECRET` / `SUPABASE_ANON_KEY` set. This is
+  a cloud-only feature.
+- `ticket: namespace not owned — regenerate your token` — the token's
+  namespace lost its owner row; regenerate from the dashboard.
+- `already running (pid N)` (exit code 2) — pidfile guard tripped,
+  another listener is active. Report and stop. Do NOT kill the other
+  listener to make room.
+- `subscribe: fatal: ...` — unhandled error. Show the user the line
+  verbatim, stop.
+
+If the process exited cleanly (exit 0) with no error line, the user
+closed the session or killed the process. Nothing to do.