cli-setu 0.2.7 → 0.2.9

package/README.md

@@ -1,6 +1,6 @@
 # cli-setu
 
-Bridge your terminal to your phone. Run Claude Code, Codex, or any plain shell on your laptop, and approve prompts, type, and watch the live output from the [CLIसेतु](https://clisetu.com) app on your phone.
+Bridge your terminal to your phone. Run Claude Code, Codex, or any plain shell on your laptop, and approve prompts, type, and watch the live output from the [cli-setu](https://clisetu.com) app on your phone.
 
 ## Install
 
@@ -16,7 +16,7 @@ cli-setu --cli claude # same, but runs Claude Code inside the bridged session
 cli-setu --cli codex  # or Codex
 ```
 
-The first time you run it, `cli-setu` prints a QR code (and an 8-digit fallback code) - scan it with the CLIसेतु app to pair this computer and start watching the session live.
+The first time you run it, `cli-setu` prints a QR code (and an 8-digit fallback code) - scan it with the cli-setu app to pair this computer and start watching the session live.
 
 Once paired, running `cli-setu` in any folder just works - no QR code needed again, unless this is a device you haven't paired before.
 
@@ -33,7 +33,7 @@ cli-setu --help    # show all commands
 
 ## How it works
 
-`cli-setu` spawns your real terminal (or Claude Code/Codex) inside a PTY, same as any terminal emulator. Every byte it produces streams live to the CLIसेतु app over a secure relay; anything you type on the phone writes back into that same PTY, exactly like a local keystroke. Permission prompts (file edits, shell commands, etc.) are detected and relayed as structured approve/reject cards instead of raw text, when the adapter for your CLI supports it.
+`cli-setu` spawns your real terminal (or Claude Code/Codex) inside a PTY, same as any terminal emulator. Every byte it produces streams live to the cli-setu app over a secure relay; anything you type on the phone writes back into that same PTY, exactly like a local keystroke. Permission prompts (file edits, shell commands, etc.) are detected and relayed as structured approve/reject cards instead of raw text, when the adapter for your CLI supports it.
 
 ## License
 

package/bin/setu.js

@@ -91,7 +91,7 @@ async function main() {
   const config = readConfig();
   if (!config || !config.deviceToken) {
     const { pair } = require('../src/pair');
-    await pair(AUTH_SERVER, AUTH_SERVER_PUBLIC);
+    await pair(AUTH_SERVER, AUTH_SERVER_PUBLIC, { standalone: false });
   }
   require('../src/supervisor');
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cli-setu",
-  "version": "0.2.7",
+  "version": "0.2.9",
   "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

@@ -8,7 +8,7 @@ const qrcode = require('qrcode-terminal');
 const { loadOrCreateConfig, writeConfig, hasKeypair } = require('./config');
 const { generateKeypair, publicKeyToBase64, privateKeyToBase64 } = require('./crypto');
 
-async function pair(authServer, authServerPublic) {
+async function pair(authServer, authServerPublic, { standalone = true } = {}) {
   const config = loadOrCreateConfig();
 
   // Section 1 E2E: generate this device's own keypair up front, before
@@ -125,6 +125,20 @@ async function pair(authServer, authServerPublic) {
     }
   }
 
+  // Real gap found by testing (PM report): a first-time user had no clear
+  // next step after pairing succeeded - pairing a device and starting a
+  // real terminal session are deliberately separate commands (one laptop
+  // can run several sessions, switch CLIs across restarts, etc.), but
+  // nothing here ever told a first-time user that distinction, or what
+  // to actually type next. Only shown for an explicit, standalone
+  // `cli-setu pair` - bin/setu.js's own bare-`cli-setu` flow calls this
+  // function too (auto-pairing an unpaired machine before immediately
+  // starting a session right after), where this message would be
+  // immediately followed by the session actually starting anyway.
+  if (standalone) {
+    console.log('[cli-setu] Run `cli-setu` in a project folder to start your first session.');
+  }
+
   return config;
 }
 

package/src/supervisor.js

@@ -275,6 +275,12 @@ async function connectToAzure() {
   }
   const conn = await res.json();
   deviceId = conn.deviceId;
+  // See this function's own call site (main()'s former focusTimer
+  // comment) for why this starts HERE and not unconditionally at
+  // startup - deviceId must be real before pollFocus's heartbeat is
+  // worth sending at all. Guarded so a reconnect (connectToAzure called
+  // again after a dropped WebSocket) never stacks a second timer.
+  if (!focusTimer) focusTimer = setInterval(pollFocus, 2000);
   log(`[supervisor] Connecting to Azure as device:${deviceId} (owner: ${conn.userId})...`);
   // Diagnostic found by testing: a session not appearing in the phone's
   // Terminal tab had no visible cause from the laptop's own side - this
@@ -1296,15 +1302,20 @@ async function main() {
   // ptyProcess.onExit's cleanup still has a valid, harmless no-op target.
 
   pollTimer = setInterval(pollForRequests, POLL_INTERVAL_MS);
-  // Real gap found by testing: closing the shell directly (no graceful
-  // Ctrl+C) leaves no explicit "I'm done" signal for the Backend at all
-  // (see this function's onExit handler) - the ONLY way a dead session
-  // ever stops showing live on the phone is this heartbeat simply going
-  // quiet long enough for auth-server.js's own LIVE_SESSION_STALE_MS to
-  // notice. 2000ms (was 3000ms) keeps a comfortable multiple of margin
-  // under that window (now 7000ms) even if a poll or two is delayed,
-  // while detecting a real disconnect meaningfully faster than before.
-  focusTimer = setInterval(pollFocus, 2000);
+  // Real bug found by testing (PM report: "device shows offline after
+  // connecting"): focusTimer used to start HERE, unconditionally, before
+  // connectToAzure() (called at the bottom of this function, unawaited)
+  // had any chance to resolve its /device/connect call and set the real
+  // deviceId below. pollFocus's own deviceId-aware URL building silently
+  // omits the heartbeat whenever deviceId is still null - harmless for a
+  // couple of ticks on a normal fast connect, but genuinely persistent
+  // (heartbeat omitted for the ENTIRE outage) whenever /device/connect is
+  // stuck in its own 3s retry loop (network hiccup, backend restart) -
+  // every tick silently did nothing, with no visible error, for as long
+  // as that retry loop ran. Moved to start right where deviceId itself
+  // gets set, inside connectToAzure() (see its own comment there) -
+  // "Offline" on the phone now correctly means "genuinely not
+  // connected," never "connected, but the heartbeat hasn't started yet."
   // CLI-agnostic - runs for every adapter (Claude Code, Codex, generic),
   // since battery is a property of the LAPTOP, not of whatever CLI it
   // happens to be running.