svcloud 0.1.6 → 0.1.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "svcloud",
-  "version": "0.1.6",
+  "version": "0.1.7",
   "description": "The SV Cloud CLI. Alpha: login, logout, status, open, projects list, mcp, init, and runs are built; see PLANNING.md for what's still missing.",
   "type": "module",
   "license": "UNLICENSED",

package/src/lib/credentials.ts

@@ -145,15 +145,44 @@ async function linuxClear(): Promise<void> {
  * Windows Credential Manager has no CLI that can both write and read a
  * secret back out (`cmdkey` is write-only), so this goes through
  * PowerShell's P/Invoke of advapi32's CredWrite/CredRead/CredDelete
- * directly — untested on Windows (this CLI was built and verified on
- * macOS); any failure here falls back to the plaintext file below rather
- * than surfacing a build-only error to a novice.
+ * directly. Verified on Windows 11 / PowerShell 5.1 on 2026-09-18, after
+ * it had never once worked: two defects, and the second is why the first
+ * was invisible for so long.
+ *
+ * 1. The prologue passed `-UsingNamespace System.Runtime.InteropServices`.
+ *    `Add-Type -MemberDefinition` ALREADY emits that using directive, so
+ *    this produced a second one — CS0105 — and Add-Type compiles
+ *    warnings-as-errors, so the type never came into existence and every
+ *    `[SvCloud.Cred]::...` call below failed with "Unable to find type".
+ *    Do not re-add it; the directive is implicit.
+ *
+ * 2. Neither failure set a non-zero exit code. Add-Type's compile error and
+ *    the subsequent "type not found" are both NON-TERMINATING errors, and
+ *    `powershell -Command` exits 0 after them, so `execFile` saw success:
+ *    `platformSave` returned true, the plaintext fallback never fired, and
+ *    the token went nowhere. `svcloud login` printed no error and every
+ *    later command said "Not signed in" — which reads as a server bug.
+ *    Hence `$ErrorActionPreference` plus the `trap`: any terminating error
+ *    now exits 1, which is the only thing `run()` can actually detect.
+ *
+ * `platformSave` additionally reads back what it wrote (see there), so a
+ * store that accepts a write it cannot return is treated as no store at
+ * all, on every platform rather than just this one.
  */
 function psTarget(): string {
   return `${CREDENTIAL_SERVICE}/${credentialAccount()}`;
 }
 
-const PS_PROLOGUE = `
+/**
+ * Exported only so `test/windows-credentials.test.ts` can pin the two
+ * defects above from any platform — the same reason `planBrowserLaunch` is
+ * split out of `openBrowser`. Neither is reproducible on the machines this
+ * CLI is developed on, and both failed silently, so the shape is worth
+ * asserting directly rather than trusting a reviewer to notice.
+ */
+export const PS_PROLOGUE = `
+$ErrorActionPreference = "Stop"
+trap { [Console]::Error.WriteLine($_.Exception.Message); exit 1 }
 Add-Type -Namespace SvCloud -Name Cred -MemberDefinition @'
 [DllImport("advapi32.dll", SetLastError=true, CharSet=CharSet.Unicode)]
 public static extern bool CredWrite(ref CREDENTIAL credential, uint flags);
@@ -170,7 +199,7 @@ public struct CREDENTIAL {
   public uint Persist; public uint AttributeCount; public IntPtr Attributes;
   public string TargetAlias; public string UserName;
 }
-'@ -UsingNamespace System.Runtime.InteropServices
+'@
 `;
 
 async function windowsSave(json: string): Promise<void> {
@@ -232,16 +261,30 @@ async function fallbackClear(): Promise<void> {
   await rm(fallbackFile(), { force: true });
 }
 
+/**
+ * Returns true only if the keychain both accepted the write AND hands the
+ * same bytes back. The read-back is the point: a store that swallows a write
+ * and then returns nothing is WORSE than an absent one, because `saveTokens`
+ * treats it as done and the plaintext fallback never runs — so `svcloud
+ * login` reports success, stores nothing anywhere, and every later command
+ * says "Not signed in" with no error to explain it. That is exactly how the
+ * Windows path failed from its introduction until 2026-09-18 (see the
+ * Windows section's header). Verifying here rather than in `windowsSave`
+ * covers all three platforms, since nothing about the trap is specific to
+ * this one: a locked macOS Keychain or a container with no Secret Service
+ * would land the same way. A mismatch degrades to the documented plaintext
+ * file with its warning, which is a working sign-in.
+ */
 async function platformSave(json: string): Promise<boolean> {
   try {
     if (process.platform === "darwin") await macosSave(json);
     else if (process.platform === "linux") await linuxSave(json);
     else if (process.platform === "win32") await windowsSave(json);
     else return false;
-    return true;
   } catch {
     return false;
   }
+  return (await platformLoad()) === json;
 }
 
 async function platformLoad(): Promise<string | undefined> {

package/src/lib/self.ts

@@ -18,6 +18,12 @@
  * used rather than the npm shim: the shim's exec bit and its `.cmd`
  * wrapper on Windows are two more things that can be wrong, and
  * `process.execPath` is neither.
+ *
+ * ON WINDOWS THE BARE NAME IS NEVER WRITTEN, whatever PATH says — see
+ * `planBridgeCommand`. That is a separate question from whether the
+ * OWNER's shell can reach `svcloud`, which is what `isOnPath` answers and
+ * what `mcp check` reports; the two were previously the same code path and
+ * are now deliberately not.
  */
 import { accessSync, constants } from "node:fs";
 import { delimiter, dirname, join } from "node:path";
@@ -29,23 +35,76 @@ export function ownBinPath(): string {
   return join(here, "..", "..", "bin", "svcloud.js");
 }
 
+/** Windows' documented default when PATHEXT is unset. */
+const DEFAULT_PATHEXT = ".COM;.EXE;.BAT;.CMD";
+
 /**
- * Whether a bare `svcloud` resolves to an executable on this PATH.
+ * The suffixes a bare name may resolve through on this platform.
+ *
+ * Windows has no execute BIT. `accessSync(..., X_OK)` is documented as
+ * having no effect there and degrades to a plain existence check, and
+ * `chmodSync` only toggles the read-only flag — so on Windows the suffix
+ * list is the ONLY thing carrying the meaning of "executable", and it has
+ * to come from PATHEXT rather than a hardcoded guess. (A real machine's
+ * PATHEXT is longer than the four anyone hardcodes: the one this was
+ * verified on carries twelve, `.JS` among them.)
+ *
+ * The extensionless file is deliberately NOT accepted on Windows, and that
+ * is the decision worth knowing here. `npm install -g svcloud` writes
+ * THREE shims — `svcloud`, `svcloud.cmd` and `svcloud.ps1` — and only the
+ * bare one is unrunnable by cmd.exe, PowerShell and CreateProcess alike.
+ * Git Bash would run it, which is the argument for keeping it, but every
+ * real global install has the `.cmd` beside it, so accepting the bare file
+ * changes the answer only when the `.cmd` is ABSENT — precisely the case
+ * where claiming "on PATH" would be wrong for two of the three shells a
+ * Windows owner might be in. Being wrong in that direction is the
+ * expensive one: a false yes leaves an owner believing a broken install is
+ * fine, while a false no costs a `pathHint` nobody is harmed by.
+ */
+export function executableSuffixes(
+  platform: NodeJS.Platform,
+  env: NodeJS.ProcessEnv = process.env,
+): string[] {
+  if (platform !== "win32") return [""];
+  const raw = env.PATHEXT ?? DEFAULT_PATHEXT;
+  const parsed = raw
+    .split(";")
+    .map((ext) => ext.trim())
+    .filter(Boolean);
+  // An empty or whitespace-only PATHEXT is a broken environment, not an
+  // instruction to accept every extensionless file on PATH.
+  return parsed.length > 0 ? parsed : DEFAULT_PATHEXT.split(";");
+}
+
+/**
+ * Whether a bare `svcloud` resolves to something the OWNER'S SHELL would
+ * run, on this PATH.
  *
  * Deliberately not `which`/`where`: spawning a shell to answer a question
  * about the environment we are already in is slower and less predictable
- * than reading PATH ourselves. On Windows a bare name is resolved against
- * PATHEXT, so the shim's real filename there is `svcloud.cmd`.
+ * than reading PATH ourselves.
+ *
+ * This answers a question about a shell, NOT about what a harness can
+ * spawn — those differ on Windows, and conflating them is what
+ * `planBridgeCommand` now keeps apart. `mcp check` reports this one to the
+ * owner; the config written to disk does not depend on it there.
+ *
+ * `name` is assumed to carry no extension of its own (its only caller
+ * passes the default): on Windows every candidate is `name` + a PATHEXT
+ * suffix, so passing `"svcloud.cmd"` would look for `svcloud.cmd.exe`.
  */
 export function isOnPath(name = "svcloud", env: NodeJS.ProcessEnv = process.env): boolean {
   const raw = env.PATH ?? env.Path ?? "";
   if (!raw) return false;
-  const suffixes = process.platform === "win32" ? [".cmd", ".exe", ".bat", ""] : [""];
+  // X_OK means something only where an execute bit exists; see
+  // `executableSuffixes` for why Windows checks mere existence instead.
+  const mode = process.platform === "win32" ? constants.F_OK : constants.X_OK;
+  const suffixes = executableSuffixes(process.platform, env);
   for (const dir of raw.split(delimiter)) {
     if (!dir) continue;
     for (const suffix of suffixes) {
       try {
-        accessSync(join(dir, `${name}${suffix}`), constants.X_OK);
+        accessSync(join(dir, `${name}${suffix}`), mode);
         return true;
       } catch {
         /* Not here; keep looking. */
@@ -62,10 +121,48 @@ export interface BridgeCommand {
   onPath: boolean;
 }
 
+/**
+ * Split out of `bridgeCommand` so the Windows rule is testable from the
+ * platforms this CLI is actually developed on — the same reason
+ * `planBrowserLaunch` exists in `lib/browser.ts`.
+ *
+ * ON WINDOWS THE BARE NAME IS REFUSED EVEN WHEN IT IS ON PATH. A harness
+ * starts an MCP server by spawning a child process, and Node's default is
+ * `shell: false`. Measured on Windows 11 / Node 24.19 against the shims
+ * `npm install -g svcloud` really writes:
+ *
+ *   spawn("svcloud",     …)  no shell → ENOENT  — CreateProcess appends
+ *                                        only `.exe`, and npm writes no
+ *                                        `svcloud.exe`; PATHEXT is a
+ *                                        SHELL's rule, not CreateProcess's
+ *   spawn("svcloud.cmd", …)  no shell → EINVAL  — Node refuses to spawn
+ *                                        .cmd/.bat without a shell at all
+ *                                        (the CVE-2024-27980 mitigation)
+ *   spawn(execPath, [binPath])  no shell → works
+ *
+ * So on Windows `isOnPath` being true says the owner's shell can reach
+ * `svcloud`, and says nothing about whether a harness can — writing the
+ * bare name there produces exactly the failure this file exists to
+ * prevent: a server that never starts, with no error the owner ever sees.
+ * The absolute form works with or without a shell, so Windows always gets
+ * it. `onPath` reports the form that was CHOSEN, not what PATH holds;
+ * `mcp check` calls `isOnPath` directly for the latter.
+ */
+export function planBridgeCommand(
+  platform: NodeJS.Platform,
+  onPath: boolean,
+  execPath: string,
+  binPath: string,
+): BridgeCommand {
+  if (platform !== "win32" && onPath) {
+    return { command: "svcloud", args: ["mcp"], onPath: true };
+  }
+  return { command: execPath, args: [binPath, "mcp"], onPath: false };
+}
+
 /** The `command` + `args` a harness config should use to run `svcloud mcp`. */
 export function bridgeCommand(): BridgeCommand {
-  if (isOnPath()) return { command: "svcloud", args: ["mcp"], onPath: true };
-  return { command: process.execPath, args: [ownBinPath(), "mcp"], onPath: false };
+  return planBridgeCommand(process.platform, isOnPath(), process.execPath, ownBinPath());
 }
 
 /**