cli-setu 0.2.4 → 0.2.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cli-setu",
-  "version": "0.2.4",
+  "version": "0.2.6",
   "description": "Bridge your terminal to your phone — run and approve Claude Code, Codex CLI and other AI coding agents from anywhere.",
   "type": "commonjs",
   "bin": {

package/src/status.js

@@ -24,26 +24,49 @@ async function status(authServer) {
     console.log('[cli-setu] Not paired. Run `cli-setu pair` to get started.');
     return;
   }
-  console.log(`[cli-setu] Paired as "${config.deviceName}".`);
 
-  // Real gap found by testing with multiple real accounts across multiple
-  // laptops: there was no way to confirm which Google account a laptop was
-  // paired to without checking the phone app directly - the device token
-  // itself carries no human-readable identity. Best-effort: a network
-  // failure here shouldn't block the rest of `status` from reporting what
-  // it already knows locally.
+  // Real bug found by testing: this used to print "Paired as X" straight
+  // from the local config file with no server check at all - unpairing
+  // from the PHONE deletes the device server-side, but the laptop's own
+  // config.json still has the old (now-dead) token, so `status` kept
+  // claiming the device was paired indefinitely, with nothing telling the
+  // user their session was actually dead until something else failed
+  // later. Same real distinction pair.js's own re-pair check already
+  // makes: a 401 means the server genuinely doesn't recognize this token
+  // anymore (deliberately re-pairable from here); a network error/
+  // unreachable server is a THIRD, distinct outcome, not treated as
+  // "unpaired" - it falls through to reporting local state as before,
+  // same as this check not existing, so a flaky-wifi run doesn't get
+  // told it's unpaired when it might just be offline.
+  let serverSaysUnpaired = false;
+  let userId = null;
   try {
     const whoamiRes = await fetch(`${authServer}/device/whoami`, {
       headers: { Authorization: `Bearer ${config.deviceToken}` },
     });
     if (whoamiRes.ok) {
-      const { userId } = await whoamiRes.json();
-      console.log(`[cli-setu] Paired to account: ${userId}`);
+      ({ userId } = await whoamiRes.json());
+    } else if (whoamiRes.status === 401) {
+      serverSaysUnpaired = true;
     }
   } catch {
     // Offline, or the server's unreachable - status still works from local state alone.
   }
 
+  if (serverSaysUnpaired) {
+    // Deliberately NOT returning here - a `cli-setu` process can still be
+    // genuinely running (pointlessly retrying against this now-dead
+    // token, see supervisor.js's own 401 handling), and the user should
+    // still be told that so they know to `cli-setu stop` it rather than
+    // it silently retrying in the background forever.
+    console.log(`[cli-setu] "${config.deviceName}" was unpaired from the app. Run \`cli-setu pair\` to reconnect.`);
+  } else {
+    console.log(`[cli-setu] Paired as "${config.deviceName}".`);
+    if (userId) {
+      console.log(`[cli-setu] Paired to account: ${userId}`);
+    }
+  }
+
   let files;
   try {
     files = fs.readdirSync(CONFIG_DIR).filter((f) => f.startsWith('session.') && f.endsWith('.pid'));

package/src/supervisor.js

@@ -544,25 +544,22 @@ function flushOutputBuffer() {
 
   // Still serialized against any send already in flight, so batches
   // themselves can never arrive out of order relative to each other.
+  // Real bug found by testing: the Backend used to AWAIT Azure's own
+  // sendToAll broadcast (~190-200ms per call, confirmed inherent to
+  // Azure Web PubSub's broadcast API, not fixable from our side) before
+  // responding here - since this chain won't send its next batch until
+  // this fetch() resolves, every Azure call directly delayed the next
+  // batch too, compounding into real, visible lag during a burst of PTY
+  // output. auth-server.js's /relay/terminal-output now responds
+  // immediately and broadcasts to Azure in the background, so this
+  // fetch() itself should resolve quickly regardless of Azure's own cost.
   sendInFlight = sendInFlight.then(async () => {
-    // TEMPORARY diagnostic (remove once the real lag source is found):
-    // measures the full fetch() round trip to the Backend, isolating "is
-    // the laptop's own network connection to the Backend slow" from
-    // Azure's broadcast time (measured separately, server-side, in
-    // auth-server.js's /relay/terminal-output handler) and from this
-    // batch's own BATCH_WINDOW_MS wait (not included here - that delay is
-    // intentional, not a bug).
-    const sendStart = Date.now();
     try {
       await fetch(`${AUTH_SERVER}/relay/terminal-output`, {
         method: 'POST',
         headers: { 'Content-Type': 'application/json', Authorization: `Bearer ${deviceToken}` },
         body: JSON.stringify({ sessionId: SESSION_ID, seq: ++outputSeq, data: batch }),
       });
-      const sendMs = Date.now() - sendStart;
-      if (sendMs > 150) {
-        log(`[perf] terminal-output POST took ${sendMs}ms (bytes=${batch.length})`);
-      }
     } catch (err) {
       // A dropped terminal.output batch isn't fatal the way a dropped
       // confirmation would be - the next batch (or a fresh session.attach