troxy-cli 1.29.8 → 1.29.10

package/bin/troxy.js

@@ -573,7 +573,7 @@ switch (command) {
     // is its picture of which checkpoints exist, and that lives on the server.
     // This is a no-op on a machine with an MCP client, which gets a fresh tool
     // list from the MCP handshake every session anyway.
-    const { refreshHostedInstructions, reprovisionKeyConsumers } = await import('../src/init.js');
+    const { refreshHostedInstructions } = await import('../src/init.js');
     const refresh = async () => {
       try {
         return await refreshHostedInstructions((loadConfig() || {}).apiKey);
@@ -614,10 +614,38 @@ switch (command) {
       // until someone thought to re-run `init` by hand. Best-effort: a
       // failure here must not make `update` itself look like it failed when
       // the actual package upgrade already succeeded.
+      //
+      // Found live 2026-09-13: this used to call reprovisionKeyConsumers()
+      // in-process via a dynamic import of ../src/init.js. That import is
+      // resolved by Node's ES module cache, which is keyed by file URL, not
+      // re-checked against disk - and this same process already loaded
+      // ../src/init.js (transitively, via bin/troxy.js's own top-of-file
+      // static imports) back when it STARTED, i.e. running the version
+      // being upgraded FROM. The npm install above only changes what's on
+      // disk; it can't evict this process's already-cached module graph.
+      // So every "provision the just-installed version" step here was
+      // actually running the PREVIOUS version's code - invisible unless
+      // that code path itself changed between versions, which is exactly
+      // what happened with the gui/user launchd domain fix (1.29.9): update
+      // correctly installed 1.29.9's files, then reprovisioned using
+      // 1.29.8's stale in-memory launchdUserDomain(), reintroducing the
+      // bug `troxy update` had just shipped the fix for. A dynamic import,
+      // no matter where or how it's written, can't fix this - it needs an
+      // actual new OS process, which loads ../src/init.js fresh from the
+      // now-updated disk. Hence shelling out to the just-installed binary's
+      // own hidden `_reprovision` command instead of calling the function
+      // directly.
       const savedConfig = loadConfig();
       if (savedConfig?.apiKey) {
         try {
-          await reprovisionKeyConsumers(savedConfig.apiKey, savedConfig.agentName);
+          const { execFileSync } = await import('child_process');
+          const globalRoot = execSync('npm root -g', { stdio: 'pipe' }).toString().trim();
+          const freshBin = `${globalRoot}/troxy-cli/bin/troxy.js`;
+          execFileSync(process.execPath, [
+            freshBin, '_reprovision',
+            '--key', savedConfig.apiKey,
+            '--name', savedConfig.agentName || 'my-agent',
+          ], { stdio: 'inherit' });
         } catch (err) {
           console.error(`\n  Could not refresh MCP client config: ${err.message}`);
           console.error('  Run "troxy init --key <your-key>" by hand to finish updating.\n');
@@ -639,6 +667,18 @@ switch (command) {
     break;
   }
 
+  // Internal, undocumented - not for direct use. `update` shells out to
+  // this in a brand new process (see the comment at its call site) purely
+  // to force a fresh, on-disk read of ../src/init.js after an in-place
+  // npm upgrade, instead of reusing this same process's already-cached
+  // module graph from the pre-upgrade version.
+  case '_reprovision': {
+    if (!flags.key) process.exit(1);
+    const { reprovisionKeyConsumers } = await import('../src/init.js');
+    await reprovisionKeyConsumers(flags.key, flags.name || 'my-agent');
+    break;
+  }
+
   // ── Help / default ────────────────────────────────────────────
   default:
     if (command) console.error(`  Unknown command: ${command}\n`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "troxy-cli",
-  "version": "1.29.8",
+  "version": "1.29.10",
   "description": "A secure control layer for AI agents: policies across payments, messages, logins, destructive actions, model usage, and secrets, all enforceable from the CLI",
   "homepage": "https://troxy.io",
   "bugs": {

package/src/launchd.js

@@ -22,11 +22,21 @@
 // bootstrap into their own domain the same way. Works correctly either
 // way, unlike load/unload.
 //
-// user/<uid>, not gui/<uid>: troxy's daemon needs no GUI/Aqua session, and
-// troxy explicitly targets "your laptop, a server, a VM" (see the CLI's
-// own README) - a server or VM may have no GUI login at all, where
-// gui/<uid> would fail outright. user/<uid> exists as soon as the user is
-// logged in at all, GUI or headless SSH-only alike.
+// gui/<uid>, NOT user/<uid> - corrected 2026-09-12 after shipping user/<uid>
+// first and getting this wrong in practice: a real, normal (non-sudo)
+// `troxy update` run then failed with "Bootstrap failed: 5: Input/output
+// error" bootstrapping into user/501. `man launchctl` confirms why - gui
+// and user are DISCRETE domains with their own separate sets of services
+// (not two names for the same thing), and Apple's own canonical example in
+// that same man page loads a per-user service into gui/<uid>, not
+// user/<uid>. The original reasoning for user/<uid> (a server/VM might
+// have no GUI login) doesn't actually apply here: this whole branch is
+// darwin-only, and a Mac running Troxy for Claude Desktop already requires
+// an active GUI session for Claude Desktop itself to run at all - the
+// "headless Mac" case this was trying to additionally support isn't a
+// real configuration for this specific daemon. Lesson: this got shipped
+// on man-page reading plus reasoning about what SHOULD work, not on
+// checking a real bootstrap call - the second attempt fixed that.
 
 /**
  * The launchd domain-target to bootstrap/bootout ai.troxy.mcp.plist into -
@@ -40,5 +50,5 @@
  */
 export function launchdUserDomain(env = process.env, getuid = () => process.getuid?.()) {
   const uid = env.SUDO_UID || String(getuid() ?? '');
-  return `user/${uid}`;
+  return `gui/${uid}`;
 }

package/src/tests/launchd.test.js

@@ -23,17 +23,17 @@ const uninstallSrc = readFileSync(join(__dirname, '..', 'uninstall.js'), 'utf8')
 describe('launchdUserDomain', () => {
   it('uses SUDO_UID when running under sudo, ignoring the elevated (root) uid', () => {
     const domain = launchdUserDomain({ SUDO_UID: '501' }, () => 0);
-    assert.equal(domain, 'user/501');
+    assert.equal(domain, 'gui/501');
   });
 
   it('falls back to the caller\'s own uid when not running under sudo', () => {
     const domain = launchdUserDomain({}, () => 501);
-    assert.equal(domain, 'user/501');
+    assert.equal(domain, 'gui/501');
   });
 
   it('prefers SUDO_UID even if somehow both are present', () => {
     const domain = launchdUserDomain({ SUDO_UID: '501' }, () => 0);
-    assert.notEqual(domain, 'user/0');
+    assert.notEqual(domain, 'gui/0');
   });
 
   it('never throws when getuid is unavailable (e.g. non-POSIX platform)', () => {

package/src/tests/update-reprovision.test.js

@@ -0,0 +1,82 @@
+// Found live 2026-09-13: `troxy update`'s post-install reprovisioning step
+// used to call reprovisionKeyConsumers() in-process via a dynamic import of
+// ../src/init.js. Node's ES module cache is keyed by file URL and is never
+// re-checked against disk - bin/troxy.js's own top-of-file static imports
+// already pull in ../src/init.js the moment the process starts, i.e. running
+// whatever version is being upgraded FROM. `npm install -g` only changes
+// files on disk; it can't evict this process's already-cached module graph.
+// So the "provision the just-installed version" step was silently always
+// running the PREVIOUS version's code - invisible unless that exact code
+// path changed between versions, which is exactly what happened with the
+// gui/user launchd domain fix (1.29.9): update correctly installed 1.29.9's
+// files, then reprovisioned using 1.29.8's stale in-memory
+// launchdUserDomain(), reintroducing the very bug that release shipped the
+// fix for. The fix is bin/troxy.js's `update` case shelling out (via
+// execFileSync, a real new OS process) to the just-installed binary's own
+// hidden `_reprovision` command, which loads ../src/init.js fresh from the
+// now-updated disk - a dynamic import from the still-running update process
+// can't do this no matter where it's written.
+
+import { describe, it } from 'node:test';
+import assert from 'node:assert/strict';
+import { readFileSync } from 'node:fs';
+import { fileURLToPath } from 'node:url';
+import { dirname, join } from 'node:path';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const troxySrc = readFileSync(join(__dirname, '..', '..', 'bin', 'troxy.js'), 'utf8');
+
+function updateCaseBody(src) {
+  const start = src.indexOf("case 'update':");
+  assert.ok(start !== -1, "case 'update' not found");
+  const end = src.indexOf("case '_reprovision':", start);
+  assert.ok(end !== -1, "case '_reprovision' not found after 'update'");
+  return src.slice(start, end);
+}
+
+describe("update case: reprovisions via a fresh subprocess, not an in-process import", () => {
+  it('does not call reprovisionKeyConsumers directly inside the update case', () => {
+    const body = updateCaseBody(troxySrc);
+    assert.doesNotMatch(body, /await reprovisionKeyConsumers\(/,
+      'must not call reprovisionKeyConsumers() in-process - that reuses this process\'s pre-upgrade module cache');
+  });
+
+  it('no longer destructure-imports reprovisionKeyConsumers into the update case', () => {
+    const body = updateCaseBody(troxySrc);
+    assert.doesNotMatch(body, /\{[^}]*reprovisionKeyConsumers[^}]*\} = await import/,
+      'the whole point of the fix is that update never binds the in-process function');
+  });
+
+  it('still imports refreshHostedInstructions in-process (unaffected by this bug)', () => {
+    const body = updateCaseBody(troxySrc);
+    assert.match(body, /const \{ refreshHostedInstructions \} = await import\('\.\.\/src\/init\.js'\);/);
+  });
+
+  it('shells out to a freshly-resolved binary path via execFileSync, not the running process\'s own code', () => {
+    const body = updateCaseBody(troxySrc);
+    assert.match(body, /execFileSync\(/, 'must spawn a real new process to force a fresh disk read');
+    assert.match(body, /npm root -g/, 'must resolve the just-installed package location, not assume one');
+    assert.match(body, /_reprovision/, 'must invoke the hidden _reprovision entry point');
+  });
+
+  it('passes the API key as a separate argv entry, not interpolated into a shell string', () => {
+    const body = updateCaseBody(troxySrc);
+    const callIdx = body.indexOf('execFileSync(process.execPath, [');
+    assert.ok(callIdx !== -1, 'expected execFileSync(process.execPath, [...]) call shape');
+    const callBlock = body.slice(callIdx, body.indexOf(');', callIdx));
+    assert.doesNotMatch(callBlock, /`[^`]*\$\{savedConfig\.apiKey\}/,
+      'the key must not be template-interpolated into a shell-executed string');
+    assert.match(callBlock, /'--key',\s*savedConfig\.apiKey/);
+  });
+});
+
+describe("'_reprovision': hidden entry point the update subprocess invokes", () => {
+  it('exists, requires --key, and calls reprovisionKeyConsumers with fresh flags', () => {
+    const start = troxySrc.indexOf("case '_reprovision':");
+    assert.ok(start !== -1, "case '_reprovision' not found");
+    const block = troxySrc.slice(start, start + 500);
+    assert.match(block, /if \(!flags\.key\) process\.exit\(1\);/);
+    assert.match(block, /await import\('\.\.\/src\/init\.js'\)/);
+    assert.match(block, /reprovisionKeyConsumers\(flags\.key, flags\.name \|\| 'my-agent'\)/);
+  });
+});