cli-setu 0.3.1 → 0.3.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cli-setu",
-  "version": "0.3.1",
+  "version": "0.3.2",
   "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/cli-adapters/claude.js

@@ -19,6 +19,7 @@
 // regex for exactly what shape it expects today.
 const fs = require('fs');
 const path = require('path');
+const { resolveWindowsBin } = require('./resolveWindowsBin');
 
 function queueFileFor(baseDir, cwd) {
   const safeName = cwd.replace(/[\\/:]/g, '_');
@@ -249,10 +250,7 @@ module.exports = {
   // icon + color stands in until a real logo image is supplied.
   icon: { name: 'sparkles', color: '#D97757' }, // Anthropic's own public brand accent is a terracotta/orange - approximated here, not an official value
   spawn: {
-    command:
-      process.platform === 'win32'
-        ? 'C:\\Users\\hp\\AppData\\Roaming\\npm\\claude.cmd'
-        : 'claude',
+    command: process.platform === 'win32' ? resolveWindowsBin('claude') : 'claude',
     args: () => ['--permission-mode', 'default'],
   },
   approvals: {

package/src/cli-adapters/codex.js

@@ -48,6 +48,8 @@
 //   laptop/folder doesn't stall waiting on a phone tap for a purely local
 //   one-time step - see supervisor-qr.js's onData handler for where this
 //   gets called before real-approval detection even runs.
+const { resolveWindowsBin } = require('./resolveWindowsBin');
+
 const ONBOARDING_TRUST_RE = /do you trust the contents of this directory\?/i;
 const ONBOARDING_SANDBOX_RE = /set up the codex agent sandbox/i;
 
@@ -193,14 +195,12 @@ module.exports = {
   // actual logo (no official asset bundled/fabricated here).
   icon: { name: 'terminal', color: '#10A37F' }, // OpenAI's own public brand accent is a teal/green - approximated here, not an official value
   spawn: {
-    // Real, verified path (see `where codex` / `Get-Command codex` output
-    // in the project chat history) - node-pty on Windows needs a real
-    // resolved executable, the same requirement claude.js's spawn.command
-    // already works around for Claude Code.
-    command:
-      process.platform === 'win32'
-        ? 'C:\\Users\\hp\\AppData\\Roaming\\npm\\codex.cmd'
-        : 'codex',
+    // node-pty on Windows needs a real resolved executable (a bare name
+    // doesn't reliably spawn the way it does via a shell's own PATH
+    // lookup) - resolveWindowsBin finds it under the CURRENT user's own
+    // npm global bin, not one hardcoded developer machine's path (see
+    // its own comment for the real bug this fixes).
+    command: process.platform === 'win32' ? resolveWindowsBin('codex') : 'codex',
     args: () => [],
   },
   approvals: {

package/src/cli-adapters/resolveWindowsBin.js

@@ -0,0 +1,40 @@
+// Real bug found by testing (PM report - broke for every real Windows
+// tester except the one machine this was originally written on):
+// claude.js and codex.js both had their Windows spawn command HARDCODED
+// to this project's own developer machine's npm global bin path
+// (C:\Users\hp\AppData\Roaming\npm\<name>.cmd) - node-pty on Windows
+// needs a real resolved executable (a bare name like 'claude' doesn't
+// reliably spawn via node-pty the way it does via a shell's own PATH
+// lookup), but a path baked in for one specific Windows username can
+// only ever work on that one machine. Every other real user's own
+// global npm installs live under THEIR OWN username's AppData, which
+// this never accounted for - spawn() then failed with an opaque native
+// "posix_spawnp failed", with no indication the real cause was a
+// hardcoded path from a different computer entirely.
+//
+// Resolves via the current process's own environment instead: APPDATA
+// always points at the CURRENT user's roaming profile on any real
+// Windows installation, regardless of username - this is the same
+// directory `npm config get prefix`'s default resolves to for a global
+// npm install on Windows, so it is exactly where `npm install -g
+// <name>` actually places <name>.cmd.
+const path = require('path');
+const fs = require('fs');
+
+function resolveWindowsBin(name) {
+  const appData = process.env.APPDATA;
+  if (appData) {
+    const candidate = path.join(appData, 'npm', `${name}.cmd`);
+    if (fs.existsSync(candidate)) return candidate;
+  }
+  // APPDATA missing or the .cmd isn't where expected (a non-default npm
+  // prefix, a different Node version manager) - fall back to the bare
+  // name and let the OS's own PATH search handle it, same as every
+  // other platform already does. Better than throwing here: a wrong
+  // guess that still gets passed to node-pty will fail with its own
+  // real error, surfaced by supervisor.js's own spawn try/catch, rather
+  // than this file itself deciding no path exists.
+  return name;
+}
+
+module.exports = { resolveWindowsBin };

package/src/cli-adapters/shell.js

@@ -11,6 +11,30 @@
 // - detection is about what's actually running inside the PTY moment to
 // moment, not about which adapter spawned the shell around it.
 const os = require('os');
+const fs = require('fs');
+
+// Real bug found by testing (PM report, multiple real macOS users hit
+// this): node-pty's spawn() throws synchronously with an opaque native
+// "posix_spawnp failed" error - and nothing ever caught it - whenever
+// $SHELL points at a path that doesn't actually exist or isn't
+// executable anymore (a shell installed via Homebrew/nvm/asdf that was
+// later upgraded, moved, or uninstalled; a stale value left over from a
+// deleted user profile; a corporate-managed Mac with $SHELL pointing at
+// something sandboxed). This crashed the ENTIRE supervisor process on
+// startup with no actionable message - "not able to start any session"
+// was the only thing the user could see. Validating the path exists AND
+// is actually a regular file before trusting it, falling back through a
+// short list of real, almost-always-present POSIX shells, means a
+// broken $SHELL no longer takes down the whole bridge - it just quietly
+// uses a working shell instead, same as if $SHELL had never been set at
+// all.
+function isExecutableFile(path) {
+  try {
+    return fs.statSync(path).isFile();
+  } catch {
+    return false;
+  }
+}
 
 function resolveShellCommand() {
   if (process.platform === 'win32') {
@@ -27,7 +51,19 @@ function resolveShellCommand() {
   // configured shell" (bash, zsh, fish, ...) - respecting it here means
   // this bridges whatever shell the user already actually uses day to
   // day, not a hardcoded assumption that might not even be installed.
-  return process.env.SHELL || '/bin/bash';
+  // Only trusted if it actually resolves to a real file on disk right
+  // now - see isExecutableFile's own comment for why this check exists.
+  if (process.env.SHELL && isExecutableFile(process.env.SHELL)) {
+    return process.env.SHELL;
+  }
+  for (const candidate of ['/bin/zsh', '/bin/bash', '/bin/sh']) {
+    if (isExecutableFile(candidate)) return candidate;
+  }
+  // Every one of those is a standard part of macOS/Linux and should
+  // never actually be missing - this is a last-resort value, not an
+  // expected path, kept only so spawn() still gets SOME string instead
+  // of undefined.
+  return '/bin/sh';
 }
 
 module.exports = {

package/src/supervisor.js

@@ -1112,13 +1112,28 @@ async function main() {
 
   console.log(`\n[supervisor] Spawning ${adapter.displayName} in a PTY (device=${DEVICE_NAME}, session=${SESSION_ID}, cwd=${WORKING_DIR})...`);
 
-  ptyProcess = pty.spawn(adapter.spawn.command, adapter.spawn.args(WORKING_DIR), {
-    name: 'xterm-color',
-    cols: PTY_COLS,
-    rows: PTY_ROWS,
-    cwd: WORKING_DIR,
-    env: process.env,
-  });
+  try {
+    ptyProcess = pty.spawn(adapter.spawn.command, adapter.spawn.args(WORKING_DIR), {
+      name: 'xterm-color',
+      cols: PTY_COLS,
+      rows: PTY_ROWS,
+      cwd: WORKING_DIR,
+      env: process.env,
+    });
+  } catch (err) {
+    // Real bug found by testing (PM report, multiple real macOS users):
+    // node-pty's spawn() can still throw an opaque native error (e.g.
+    // "posix_spawnp failed") for reasons shell.js's own path validation
+    // doesn't cover - a CLI adapter (claude/codex) genuinely not
+    // installed/on PATH, a cwd the OS won't let this process enter, a
+    // sandboxed/restricted environment. Previously this propagated all
+    // the way up to main().catch's generic "[supervisor] fatal: <msg>"
+    // with zero context about WHAT was being spawned or WHERE - telling
+    // the user only that something failed, never why. Re-throwing with
+    // the actual command and cwd attached turns that into an actionable
+    // message instead of a dead end.
+    throw new Error(`Could not start "${adapter.spawn.command}" in ${WORKING_DIR}: ${err.message}`);
+  }
 
   ptyProcess.onData((data) => {
     process.stdout.write(data);