cli-setu 0.2.0 → 0.2.1

package/bin/setu.js

@@ -63,6 +63,11 @@ async function main() {
         await stop();
         return;
       }
+      case 'unpair': {
+        const { unpair } = require('../src/unpair');
+        await unpair(AUTH_SERVER);
+        return;
+      }
       default:
         console.error(`[cli-setu] Unknown command: ${firstArg}`);
         printHelp();
@@ -99,6 +104,7 @@ Usage:
   cli-setu pair               Pair this computer with your phone, nothing else
   cli-setu status             Show pairing status and any sessions running now
   cli-setu stop               Stop a running session
+  cli-setu unpair             Unpair this computer (asks for confirmation)
   cli-setu --version, -v      Print the installed version
   cli-setu --update           Check for and install the latest version
   cli-setu --help, -h         Show this help`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cli-setu",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "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/pair.js

@@ -11,8 +11,36 @@ async function pair(authServer, authServerPublic) {
   const config = loadOrCreateConfig();
 
   if (config.deviceToken) {
-    console.log(`[cli-setu] "${config.deviceName}" is already paired.`);
-    return config;
+    // Real bug found by testing: unpairing from the phone deletes the
+    // device server-side, but the laptop's local config.json still has
+    // the old (now-dead) token - this used to trust that local file
+    // blindly and declare itself "already paired" even when the server
+    // had no record of it at all. Confirm the saved token is actually
+    // still valid before trusting it; a dead token (401 - the server
+    // genuinely doesn't recognize it) falls through to a real re-pair.
+    // A network error/unreachable server is a THIRD, distinct outcome -
+    // deliberately NOT treated as "unpaired," since that would force an
+    // unwanted re-pair on every flaky-wifi run; it proceeds as if still
+    // paired instead, same as this check not existing at all.
+    let serverSaysUnpaired = false;
+    try {
+      const res = await fetch(`${authServer}/device/whoami`, {
+        headers: { Authorization: `Bearer ${config.deviceToken}` },
+      });
+      serverSaysUnpaired = res.status === 401;
+    } catch {
+      // Network error/unreachable - unknown, not "unpaired". Fall through
+      // to the "already paired" branch below, unchanged from before this
+      // check existed.
+    }
+
+    if (!serverSaysUnpaired) {
+      console.log(`[cli-setu] "${config.deviceName}" is already paired.`);
+      return config;
+    }
+
+    console.log(`[cli-setu] This device's pairing is no longer valid on the server (likely unpaired from the app) - re-pairing...`);
+    config.deviceToken = null;
   }
 
   console.log(`[cli-setu] Pairing as "${config.deviceName}"...`);

package/src/status.js

@@ -26,6 +26,24 @@ async function status(authServer) {
   }
   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.
+  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}`);
+    }
+  } catch {
+    // Offline, or the server's unreachable - status still works from local state alone.
+  }
+
   let files;
   try {
     files = fs.readdirSync(CONFIG_DIR).filter((f) => f.startsWith('session.') && f.endsWith('.pid'));

package/src/supervisor.js

@@ -236,6 +236,19 @@ async function connectToAzure() {
       log(`[supervisor] /device/connect rejected (403): ${err.error || 'no reason given'}`);
       process.exit(1);
     }
+    // Real bug found by testing: a 401 here means the server genuinely
+    // doesn't recognize this device token anymore (e.g. unpaired from the
+    // phone app) - this used to fall into the generic retry-every-3s path
+    // below, silently looping forever on a token that will never become
+    // valid again, with no indication to the user of what's actually
+    // wrong or what to do about it. Treated the same as 403 now: stop,
+    // say so clearly, point at the real fix.
+    if (res.status === 401) {
+      console.error(`\n[supervisor] This device is no longer paired (it may have been unpaired from the app).`);
+      console.error('[supervisor] Run `cli-setu pair` to pair it again.');
+      log(`[supervisor] /device/connect rejected (401): ${err.error || 'no reason given'}`);
+      process.exit(1);
+    }
     log(`[supervisor] /device/connect failed: ${err.error || res.status}`);
     setTimeout(connectToAzure, 3000);
     return;

package/src/unpair.js

@@ -0,0 +1,65 @@
+// `cli-setu unpair` - lets this laptop remove itself from its paired
+// account, without needing the phone app. Real gap found by testing:
+// unpairing only ever existed from the phone's Devices tab - there was no
+// way to do this from the laptop side at all, and no way to recover from
+// a stale local pairing except manually deleting ~/.cli-setu/config.json
+// by hand.
+const readline = require('readline');
+const { readConfig, writeConfig } = require('./config');
+
+function confirm(question) {
+  const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
+  return new Promise((resolve) => {
+    rl.question(question, (answer) => {
+      rl.close();
+      resolve(answer.trim().toLowerCase() === 'y');
+    });
+  });
+}
+
+async function unpair(authServer) {
+  const config = readConfig();
+  if (!config || !config.deviceToken) {
+    console.log('[cli-setu] Not paired - nothing to unpair.');
+    return;
+  }
+
+  const confirmed = await confirm(
+    `[cli-setu] This will unpair "${config.deviceName}" and stop it from connecting. Continue? (y/N) `
+  );
+  if (!confirmed) {
+    console.log('[cli-setu] Cancelled.');
+    return;
+  }
+
+  try {
+    const res = await fetch(`${authServer}/device/unpair-self`, {
+      method: 'POST',
+      headers: { Authorization: `Bearer ${config.deviceToken}` },
+    });
+    // A 404 here means the server already has no record of this device
+    // (e.g. it was unpaired from the phone app already) - that's still a
+    // successful outcome from the user's point of view, so the local
+    // config is cleared the same way as a real 200.
+    if (!res.ok && res.status !== 404) {
+      const err = await res.json().catch(() => ({}));
+      console.error(`[cli-setu] Unpair failed: ${err.error || res.status}`);
+      console.error('[cli-setu] Local pairing left untouched - try again once the server is reachable.');
+      return;
+    }
+  } catch (err) {
+    console.error(`[cli-setu] Could not reach the server: ${err.message}`);
+    console.error('[cli-setu] Local pairing left untouched - try again once you\'re back online.');
+    return;
+  }
+
+  // Only clear the local file once the server confirms - never unpair
+  // locally while leaving a real, still-active device row behind on the
+  // server (that would orphan it with no way to remove it via the CLI,
+  // since cli-setu pair would need a device token this file no longer has).
+  config.deviceToken = null;
+  writeConfig(config);
+  console.log(`[cli-setu] ✓ Unpaired. Run \`cli-setu pair\` to pair this computer again.`);
+}
+
+module.exports = { unpair };