litmus-cli 1.4.27 → 1.4.29

package/dist/lib/api-base.js

@@ -1,4 +1,5 @@
 import { FALLBACK_URL } from "./errors.js";
+import { isWorkspaceInstall } from "./workspace-token.js";
 /**
  * Resolve the frontend base URL that `litmus init` talks to — the CLI's single
  * routing decision. `LITMUS_API_URL` (which preview deployments surface to the
@@ -14,4 +15,86 @@ import { FALLBACK_URL } from "./errors.js";
 export function resolveApiBase(apiUrl) {
     return apiUrl ?? FALLBACK_URL;
 }
+/**
+ * The origin to send a `/workspace/*` or `/cli/*` request to, for the install
+ * this CLI is running from (ENG-2321).
+ *
+ * TWO ORIGINS SERVE THE SAME ROUTES AND ONLY ONE OF THEM IS REACHABLE FROM A
+ * CONTAINER. `litmus init` learns `backendUrl` from the server — it is
+ * `NEXT_PUBLIC_PYTHON_API_URL`, the Railway origin the Python backend is
+ * published at — and every later workspace call used it. That is correct on a
+ * laptop and wrong inside a Codespaces v2 workspace, whose egress deliberately
+ * does NOT carve out the orchestrator's own origin: `/internal/host/*` (hostd's
+ * register / lease / result / heartbeat channel) is served from the same host,
+ * so allowing it would hand the candidate the control plane —
+ * `infra/hostd/FLEET.md` says so in as many words, and the carve-out
+ * (`EGRESS_GATEWAY_ALLOW`) pins the APEX instead.
+ *
+ * The apex already proxies every container-facing prefix to that same backend
+ * (`frontend/next.config.mjs` rewrites `/vm/*`, `/cli/*`, `/workspace/*`,
+ * `/proxy/*`, `/mcp/*` and `/broker/*`, driven through Next's own matcher in
+ * `next.config.rewrites.test.ts`), and it is the origin the container is
+ * allowed to reach — which is exactly why ENG-2122 put the secret broker there
+ * rather than giving it a hostname of its own. So there is nothing to build:
+ * a workspace install simply has to address the route it is already entitled
+ * to use.
+ *
+ * WHAT THE BUG LOOKED LIKE, because the fingerprint is worth recognising:
+ * `litmus push` makes two hops. Hop 1 is `GET {apex}/api/cli/init` and prints
+ * `Connected — <assessment>`. Hop 2 was `POST {backendUrl}/workspace/submit`
+ * and threw `fetch failed` at the transport. **"Connected" and then "fetch
+ * failed" is this and nothing else** — a token problem answers with a status
+ * code, and an apex problem never reaches "Connected".
+ *
+ * THE PREDICATE IS `isWorkspaceInstall`, read from the caller's own module path
+ * for the reasons its docstring gives, and it is the same one ENG-2130 uses to
+ * decide which submit command a candidate is told to run. Nothing
+ * security-relevant hangs off it here either: both origins serve the same
+ * routes behind the same bearer check, so a wrong answer costs reachability,
+ * never authority.
+ *
+ * `apexBase` is the caller's already-resolved `resolveApiBase(...)` value — the
+ * deployment this CLI talks to — so a preview-provisioned workspace stays on
+ * its preview apex rather than being sent to production.
+ *
+ * THE AUDIT, so the next reader does not have to redo it. Every `backendUrl`
+ * the CLI holds comes from one of two places, and both are covered:
+ *
+ *   * FROM THE INIT METADATA, used immediately — `push` (`/workspace/submit`)
+ *     and `pause` (`/workspace/pause`), the two commands a candidate runs from
+ *     a workspace terminal. Both resolve here.
+ *   * PERSISTED INTO `.litmus/config.json` — `init`, `doctor`'s config rebuild
+ *     and the watcher's self-heal. Those resolve here too, at the WRITE, which
+ *     is what makes every later reader of a CLI-written config correct with no
+ *     change of its own: the watcher's `/cli/activity` and `/cli/snapshot`
+ *     uploads, `hook-logger.cjs`'s uploads, and `submit`'s `/cli/submit`.
+ *     `doctor` additionally resolves at its own READ, because the config in a
+ *     real container is the one hostd staged and names the Railway origin.
+ *
+ * DELIBERATELY NOT RESOLVED, each for a reason rather than an omission:
+ *
+ *   * `connect` (`/workspace/start`, `/workspace/connection`,
+ *     `/workspace/editor-chat-config`). It configures the LAPTOP — it writes
+ *     `~/.ssh/config` and launches a local editor — so it has no meaning inside
+ *     the container. And leaving it unreachable there is the SAFE state rather
+ *     than a gap: `connect` calls `ensureSshKey`, which MINTS a keypair when the
+ *     machine it runs on has none, which inside a fresh container it does not;
+ *     `/workspace/start` then hands that key to `Ops.resume`, whose
+ *     `_apply_authorized_keys` REWRITES `authorized_keys` rather than appending
+ *     (ENG-2001). So a stray `litmus connect` in a workspace terminal would
+ *     replace the candidate's own laptop key with one that exists only inside
+ *     the container they ran it from. Failing at the transport costs nothing;
+ *     succeeding would cost them their way back in.
+ *   * `submit` (`/cli/submit`). ENG-2130 refuses it in a workspace before any
+ *     network call at all; the origin it would have used never matters.
+ *   * `watcher.ts`'s and `hook-logger.cjs`'s READS of the persisted config. In
+ *     a real container that file is hostd's `_stage_litmus_config`, which
+ *     carries DELIBERATELY no token, so both lanes return before uploading
+ *     anything — they are inert there today, and the honest fix for whoever
+ *     turns the real-time in-workspace activity lane on is hostd's write, not a
+ *     second copy of this predicate in a module that imports nothing.
+ */
+export function resolveBackendBase(backendUrl, apexBase, moduleUrl) {
+    return isWorkspaceInstall(moduleUrl) ? apexBase : backendUrl;
+}
 //# sourceMappingURL=api-base.js.map

package/dist/lib/api-base.js.map

@@ -1 +1 @@
-{"version":3,"file":"api-base.js","sourceRoot":"","sources":["../../src/lib/api-base.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,MAAM,aAAa,CAAA;AAE1C;;;;;;;;;;;GAWG;AACH,MAAM,UAAU,cAAc,CAAC,MAA0B;IACvD,OAAO,MAAM,IAAI,YAAY,CAAA;AAC/B,CAAC"}
+{"version":3,"file":"api-base.js","sourceRoot":"","sources":["../../src/lib/api-base.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,MAAM,aAAa,CAAA;AAC1C,OAAO,EAAE,kBAAkB,EAAE,MAAM,sBAAsB,CAAA;AAEzD;;;;;;;;;;;GAWG;AACH,MAAM,UAAU,cAAc,CAAC,MAA0B;IACvD,OAAO,MAAM,IAAI,YAAY,CAAA;AAC/B,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8EG;AACH,MAAM,UAAU,kBAAkB,CAChC,UAAkB,EAClB,QAAgB,EAChB,SAAiB;IAEjB,OAAO,kBAAkB,CAAC,SAAS,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,UAAU,CAAA;AAC9D,CAAC"}

package/dist/lib/editor-binary.d.ts

@@ -0,0 +1,110 @@
+import type { NativeIde } from "./editor-ide.js";
+/**
+ * ENG-2332 — finding the editor's CLI when it is not on PATH, and building an argv that
+ * can actually drive it on the platform we are running on.
+ *
+ * ## Why resolution rather than a PATH probe
+ *
+ * Both editors ship their CLI inside the application bundle and put it on PATH only if
+ * the candidate has run "Shell Command: Install …" from the palette, which most people
+ * never have. Before this, `litmus connect` answered that by printing:
+ *
+ *     Warning: Cursor `cursor` command not found on PATH.
+ *       Connect manually:
+ *         cursor --remote ssh-remote+<alias> /home/candidate/workspace
+ *
+ * — a remediation that is the very binary just reported missing (reported 2026-09-15,
+ * ENG-2332). The binary was present the whole time at
+ * `/Applications/Cursor.app/Contents/Resources/app/bin/cursor`. So look there.
+ *
+ * ## A resolved path is still not an identity
+ *
+ * ENG-2152's rule holds unchanged: a command is a NAME, never a claim about which editor
+ * it is. That is true of an absolute path too — `Cursor.app` could in principle be
+ * anything, and on the PATH branch `code` routinely IS Cursor. So the caller runs the
+ * `--help` banner probe against whatever this resolves to, not against `ed.bin`.
+ *
+ * ## The list is best-effort, and knowingly incomplete on Linux
+ *
+ * macOS and Windows have installers that write to known locations. Linux does not, for
+ * Cursor especially: it ships as an AppImage a candidate can leave anywhere. The entries
+ * below are the ones a package or the vendor's own installer produces; a miss there
+ * degrades to the manual-instructions branch, which is where the candidate was already.
+ */
+/** A resolved way to reach the editor: a bare PATH name, or an absolute path we found. */
+export interface ResolvedEditorCommand {
+    /** What to hand `editorSpawnSpec`. */
+    command: string;
+    /** How we got it — the caller's output differs, and so does the advice on failure. */
+    source: "path" | "install-location";
+}
+/**
+ * Where each editor's CLI lives when its installer put it there, per platform.
+ *
+ * Paths are built with the TARGET's separator (`path.win32` / `path.posix`) and never
+ * with the bare `path`, which is bound to the host: a Windows expectation assembled with
+ * a POSIX `path` passes on a POSIX host precisely when the shipped code is wrong there.
+ * That is `chat-model-config.ts`'s `pathFor` rule, and the tests beside this assert
+ * literal strings for the same reason.
+ */
+export declare function editorInstallCandidates(ide: NativeIde, platform: NodeJS.Platform, env: NodeJS.ProcessEnv, home: string): string[];
+/**
+ * How to actually run a resolved command. Returned rather than spawned so the argv is
+ * assertable on any host — a Windows spawn cannot be exercised from a POSIX CI runner,
+ * and this is the part that is wrong if Windows is wrong.
+ *
+ * ON WINDOWS, ALWAYS A SHELL. Both editors ship their CLI as `code.cmd` / `cursor.cmd`,
+ * and CreateProcess resolves `.exe` only, so a shim-less spawn cannot run either — not
+ * the `.cmd` on PATH and not the one inside the install directory. That is ENG-2134's
+ * finding for the `--help` probe, and it is why every Windows candidate has landed on
+ * the manual-instructions branch since this command existed. The condition is the
+ * PLATFORM and not the file extension: narrowing it to `.cmd` would leave a bare `code`
+ * on a Windows PATH un-shelled, which is the pre-ENG-2134 behaviour arrived at by
+ * accident.
+ *
+ * Node does NOT quote anything when `shell: true`, so the FILE is quoted here — always,
+ * and not only when it carries whitespace. Whitespace is the spelling that made this
+ * visible (`Microsoft VS Code`), but it is not the only one that breaks, and the command
+ * is not a literal we own: `editorInstallCandidates` builds it out of `%LOCALAPPDATA%` /
+ * `%ProgramFiles%`, so a candidate whose Windows account is `a&b` resolves
+ * `C:\Users\a&b\AppData\Local\Programs\cursor\resources\app\bin\cursor.cmd` — no whitespace
+ * anywhere in it, handed to `cmd.exe` unquoted, and `&` ends the command there and starts
+ * a new one. Inside double quotes `&` is an ordinary character, so quoting unconditionally
+ * costs the bare-PATH case nothing (`cmd /d /s /c ""code" --version"` resolves `code`
+ * through PATHEXT exactly as an unquoted one does) and closes the whole family at once.
+ *
+ * Quoting the FILE is sufficient only because nothing else on the line needs it, and BOTH
+ * halves of that are asserted rather than assumed. The command is held to the narrower
+ * thing a quoted `cmd.exe` token can carry: a `"` would close the quoting just opened,
+ * and `%` is still expanded INSIDE quotes, so either refuses rather than being wrapped.
+ * Arguments are not quoted at all, so they are held to strictly less than that — `%`
+ * included, for the same reason and more directly, since there is not even a quote
+ * between it and `cmd.exe`.
+ *
+ * THE TWO GUARDS FAIL DIFFERENTLY, BECAUSE THEIR INPUTS COME FROM DIFFERENT PLACES, and
+ * an earlier cut of this had them both throw — which made a candidate's own filesystem
+ * able to abort the connection (Greptile P1 on #2442).
+ *
+ * An unsafe ARGUMENT is OUR bug. Every argument this is given is a literal we own or an
+ * alias `aliasFor` has already reduced to `[A-Za-z0-9-]`, so one that needs quoting means
+ * a later caller threaded something candidate-supplied into an argv, and throwing is the
+ * point — the invariant stated as a check rather than as a comment somebody has to keep
+ * true.
+ *
+ * An unquotable COMMAND is DATA, and it is reachable. `editorInstallCandidates` builds
+ * the command out of `%LOCALAPPDATA%` / `%ProgramFiles%`, and `%` is legal in a Windows
+ * account name, so `C:\Users\50%\AppData\Local\Programs\cursor\…\cursor.cmd` is a path a
+ * real machine can present. Throwing on it aborted `litmus connect` from inside
+ * `probeEditorCli` — after the workspace was already up — for a candidate whose only
+ * fault was their username. So this answers NULL instead: "there is no argv that drives
+ * this command on this platform". Every caller has to handle that, which the compiler
+ * enforces rather than a remembered try/catch at five call sites, and each one degrades
+ * the way it already degrades for a command that cannot be run at all.
+ */
+export interface EditorSpawnSpec {
+    command: string;
+    args: string[];
+    shell: boolean;
+}
+export declare function editorSpawnSpec(command: string, args: string[], platform: NodeJS.Platform): EditorSpawnSpec | null;
+//# sourceMappingURL=editor-binary.d.ts.map

package/dist/lib/editor-binary.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"editor-binary.d.ts","sourceRoot":"","sources":["../../src/lib/editor-binary.ts"],"names":[],"mappings":"AAEA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,iBAAiB,CAAA;AAEhD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+BG;AAEH,0FAA0F;AAC1F,MAAM,WAAW,qBAAqB;IACpC,sCAAsC;IACtC,OAAO,EAAE,MAAM,CAAA;IACf,sFAAsF;IACtF,MAAM,EAAE,MAAM,GAAG,kBAAkB,CAAA;CACpC;AAED;;;;;;;;GAQG;AACH,wBAAgB,uBAAuB,CACrC,GAAG,EAAE,SAAS,EACd,QAAQ,EAAE,MAAM,CAAC,QAAQ,EACzB,GAAG,EAAE,MAAM,CAAC,UAAU,EACtB,IAAI,EAAE,MAAM,GACX,MAAM,EAAE,CAmCV;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoDG;AACH,MAAM,WAAW,eAAe;IAC9B,OAAO,EAAE,MAAM,CAAA;IACf,IAAI,EAAE,MAAM,EAAE,CAAA;IACd,KAAK,EAAE,OAAO,CAAA;CACf;AAaD,wBAAgB,eAAe,CAC7B,OAAO,EAAE,MAAM,EACf,IAAI,EAAE,MAAM,EAAE,EACd,QAAQ,EAAE,MAAM,CAAC,QAAQ,GACxB,eAAe,GAAG,IAAI,CASxB"}

package/dist/lib/editor-binary.js

@@ -0,0 +1,72 @@
+import path from "path";
+/**
+ * Where each editor's CLI lives when its installer put it there, per platform.
+ *
+ * Paths are built with the TARGET's separator (`path.win32` / `path.posix`) and never
+ * with the bare `path`, which is bound to the host: a Windows expectation assembled with
+ * a POSIX `path` passes on a POSIX host precisely when the shipped code is wrong there.
+ * That is `chat-model-config.ts`'s `pathFor` rule, and the tests beside this assert
+ * literal strings for the same reason.
+ */
+export function editorInstallCandidates(ide, platform, env, home) {
+    if (platform === "darwin") {
+        const bundle = ide === "cursor" ? "Cursor.app" : "Visual Studio Code.app";
+        const bin = ide === "cursor" ? "cursor" : "code";
+        // A user-local install under ~/Applications is what a drag-install without admin
+        // rights produces, and is invisible to anything that only looks at /Applications.
+        return ["/Applications", path.posix.join(home, "Applications")].map((root) => path.posix.join(root, bundle, "Contents", "Resources", "app", "bin", bin));
+    }
+    if (platform === "win32") {
+        const local = env.LOCALAPPDATA;
+        const programFiles = env.ProgramFiles;
+        const programFilesX86 = env["ProgramFiles(x86)"];
+        const out = [];
+        if (ide === "cursor") {
+            // Cursor's Windows installer is per-user by default; the machine-wide option
+            // lands under Program Files with the same tree beneath it.
+            if (local)
+                out.push(path.win32.join(local, "Programs", "cursor", "resources", "app", "bin", "cursor.cmd"));
+            if (programFiles)
+                out.push(path.win32.join(programFiles, "cursor", "resources", "app", "bin", "cursor.cmd"));
+        }
+        else {
+            if (local)
+                out.push(path.win32.join(local, "Programs", "Microsoft VS Code", "bin", "code.cmd"));
+            if (programFiles)
+                out.push(path.win32.join(programFiles, "Microsoft VS Code", "bin", "code.cmd"));
+            if (programFilesX86)
+                out.push(path.win32.join(programFilesX86, "Microsoft VS Code", "bin", "code.cmd"));
+        }
+        return out;
+    }
+    // Linux. Package installs and the vendor tarballs; an AppImage left in ~/Downloads is
+    // not reachable from here and is the documented residual.
+    const bin = ide === "cursor" ? "cursor" : "code";
+    const roots = ide === "cursor"
+        ? ["/usr/share/cursor/bin", "/opt/Cursor/bin", "/opt/cursor/bin", path.posix.join(home, ".local", "bin")]
+        : ["/usr/share/code/bin", "/opt/visual-studio-code/bin", "/snap/bin", path.posix.join(home, ".local", "bin")];
+    return roots.map((root) => path.posix.join(root, bin));
+}
+const SHELL_SAFE_ARG = /^[A-Za-z0-9_@+=:,./\\-]+$/;
+/**
+ * What a quoted `cmd.exe` token cannot carry. A `"` closes the quoting this opens, `%`
+ * is expanded inside quotes, and a control character can end the line outright.
+ * Everything else — spaces, `&`, `|`, `^`, parentheses — is literal once quoted, which
+ * is why the command may hold them and an unquoted ARGUMENT may not.
+ */
+// eslint-disable-next-line no-control-regex
+const WIN32_UNQUOTABLE_COMMAND = /["%\u0000-\u001f]/;
+export function editorSpawnSpec(command, args, platform) {
+    if (platform !== "win32")
+        return { command, args, shell: false };
+    for (const a of args) {
+        if (!SHELL_SAFE_ARG.test(a))
+            throw new Error(`refusing to build a shell command line around: ${a}`);
+    }
+    // Not an error — see the block comment. A command we cannot quote is a command we
+    // cannot drive, which is the same answer as a command that will not run.
+    if (WIN32_UNQUOTABLE_COMMAND.test(command))
+        return null;
+    return { command: `"${command}"`, args, shell: true };
+}
+//# sourceMappingURL=editor-binary.js.map

package/dist/lib/editor-binary.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"editor-binary.js","sourceRoot":"","sources":["../../src/lib/editor-binary.ts"],"names":[],"mappings":"AAAA,OAAO,IAAI,MAAM,MAAM,CAAA;AA6CvB;;;;;;;;GAQG;AACH,MAAM,UAAU,uBAAuB,CACrC,GAAc,EACd,QAAyB,EACzB,GAAsB,EACtB,IAAY;IAEZ,IAAI,QAAQ,KAAK,QAAQ,EAAE,CAAC;QAC1B,MAAM,MAAM,GAAG,GAAG,KAAK,QAAQ,CAAC,CAAC,CAAC,YAAY,CAAC,CAAC,CAAC,wBAAwB,CAAA;QACzE,MAAM,GAAG,GAAG,GAAG,KAAK,QAAQ,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAA;QAChD,iFAAiF;QACjF,kFAAkF;QAClF,OAAO,CAAC,eAAe,EAAE,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,EAAE,cAAc,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAC3E,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,UAAU,EAAE,WAAW,EAAE,KAAK,EAAE,KAAK,EAAE,GAAG,CAAC,CAC1E,CAAA;IACH,CAAC;IACD,IAAI,QAAQ,KAAK,OAAO,EAAE,CAAC;QACzB,MAAM,KAAK,GAAG,GAAG,CAAC,YAAY,CAAA;QAC9B,MAAM,YAAY,GAAG,GAAG,CAAC,YAAY,CAAA;QACrC,MAAM,eAAe,GAAG,GAAG,CAAC,mBAAmB,CAAC,CAAA;QAChD,MAAM,GAAG,GAAa,EAAE,CAAA;QACxB,IAAI,GAAG,KAAK,QAAQ,EAAE,CAAC;YACrB,6EAA6E;YAC7E,2DAA2D;YAC3D,IAAI,KAAK;gBAAE,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,KAAK,EAAE,UAAU,EAAE,QAAQ,EAAE,WAAW,EAAE,KAAK,EAAE,KAAK,EAAE,YAAY,CAAC,CAAC,CAAA;YAC1G,IAAI,YAAY;gBAAE,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,YAAY,EAAE,QAAQ,EAAE,WAAW,EAAE,KAAK,EAAE,KAAK,EAAE,YAAY,CAAC,CAAC,CAAA;QAC9G,CAAC;aAAM,CAAC;YACN,IAAI,KAAK;gBAAE,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,KAAK,EAAE,UAAU,EAAE,mBAAmB,EAAE,KAAK,EAAE,UAAU,CAAC,CAAC,CAAA;YAC/F,IAAI,YAAY;gBAAE,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,YAAY,EAAE,mBAAmB,EAAE,KAAK,EAAE,UAAU,CAAC,CAAC,CAAA;YACjG,IAAI,eAAe;gBAAE,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,eAAe,EAAE,mBAAmB,EAAE,KAAK,EAAE,UAAU,CAAC,CAAC,CAAA;QACzG,CAAC;QACD,OAAO,GAAG,CAAA;IACZ,CAAC;IACD,sFAAsF;IACtF,0DAA0D;IAC1D,MAAM,GAAG,GAAG,GAAG,KAAK,QAAQ,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAA;IAChD,MAAM,KAAK,GACT,GAAG,KAAK,QAAQ;QACd,CAAC,CAAC,CAAC,uBAAuB,EAAE,iBAAiB,EAAE,iBAAiB,EAAE,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,EAAE,QAAQ,EAAE,KAAK,CAAC,CAAC;QACzG,CAAC,CAAC,CAAC,qBAAqB,EAAE,6BAA6B,EAAE,WAAW,EAAE,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,EAAE,QAAQ,EAAE,KAAK,CAAC,CAAC,CAAA;IACjH,OAAO,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,EAAE,GAAG,CAAC,CAAC,CAAA;AACxD,CAAC;AA6DD,MAAM,cAAc,GAAG,2BAA2B,CAAA;AAElD;;;;;GAKG;AACH,4CAA4C;AAC5C,MAAM,wBAAwB,GAAG,mBAAmB,CAAA;AAEpD,MAAM,UAAU,eAAe,CAC7B,OAAe,EACf,IAAc,EACd,QAAyB;IAEzB,IAAI,QAAQ,KAAK,OAAO;QAAE,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,KAAK,EAAE,KAAK,EAAE,CAAA;IAChE,KAAK,MAAM,CAAC,IAAI,IAAI,EAAE,CAAC;QACrB,IAAI,CAAC,cAAc,CAAC,IAAI,CAAC,CAAC,CAAC;YAAE,MAAM,IAAI,KAAK,CAAC,kDAAkD,CAAC,EAAE,CAAC,CAAA;IACrG,CAAC;IACD,kFAAkF;IAClF,yEAAyE;IACzE,IAAI,wBAAwB,CAAC,IAAI,CAAC,OAAO,CAAC;QAAE,OAAO,IAAI,CAAA;IACvD,OAAO,EAAE,OAAO,EAAE,IAAI,OAAO,GAAG,EAAE,IAAI,EAAE,KAAK,EAAE,IAAI,EAAE,CAAA;AACvD,CAAC"}

package/dist/lib/editor-ide.d.ts

@@ -0,0 +1,11 @@
+/**
+ * The native editors `litmus connect` can drive.
+ *
+ * It lives here rather than in `commands/connect.ts` only so that the lib modules the
+ * connect flow leans on — `editor-binary.ts`, and anything after it — can name an editor
+ * without importing the command back and closing a cycle. `connect.ts` re-exports it, so
+ * the record it belongs to (`NATIVE_EDITORS`, which carries every measured difference
+ * between the two) is still the one place that describes them.
+ */
+export type NativeIde = "vscode" | "cursor";
+//# sourceMappingURL=editor-ide.d.ts.map

package/dist/lib/editor-ide.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"editor-ide.d.ts","sourceRoot":"","sources":["../../src/lib/editor-ide.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AACH,MAAM,MAAM,SAAS,GAAG,QAAQ,GAAG,QAAQ,CAAA"}

package/dist/lib/editor-ide.js

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=editor-ide.js.map

package/dist/lib/editor-ide.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"editor-ide.js","sourceRoot":"","sources":["../../src/lib/editor-ide.ts"],"names":[],"mappings":""}

package/dist/lib/editor-server.d.ts

@@ -0,0 +1,253 @@
+/**
+ * ENG-2332 — whether a native editor can, and then DID, start its server inside the
+ * workspace. Everything here is pure or takes its one side effect as an argument, so the
+ * decisions are testable without a Cursor install and without a live container.
+ *
+ * ## The failure this exists to stop
+ *
+ * A VS Code-family editor opening a Remote-SSH window does not run anything of ours: it
+ * copies its OWN server build into the remote home and launches it there. Which build is
+ * decided by the CLIENT, by commit, and the two editors are pinned to each other — a
+ * 3.19.13 client will not talk to a 3.20.21 server, it fetches its own.
+ *
+ * A Codespaces v2 container has sealed egress. It cannot reach `api2.cursor.sh`,
+ * `downloads.cursor.com` or `github.com` (measured from inside a prod workspace,
+ * 2026-09-15: `curl` returns 000 after a 12s timeout). The only route a non-baked client
+ * has is the mirror (`infra/vscode-mirror/`, ENG-1062 for VS Code, ENG-1265 + ENG-1936
+ * for Cursor), and a mirror route that has stopped matching what a client asks for is
+ * indistinguishable, from the client's side, from no route at all.
+ *
+ * What the client does then is the whole problem: it gives up and opens the window
+ * anyway. MEASURED on macOS against a live prod workspace (ENG-2332):
+ *
+ *   - `cursor --remote ssh-remote+<alias> <dir>` exits 0 and prints nothing.
+ *   - A window appears, carrying the remote authority — `storage.json` records
+ *     `"remoteAuthority": "ssh-remote+<alias>"` — and Cursor's ordinary agent home
+ *     screen. It is indistinguishable from a working one.
+ *   - The renderer log says `Started local extension host`, and every
+ *     `$updateShellExecCapabilities` is refused as `non-authoritative host`.
+ *   - Nothing under `~/.cursor-server` on the VM is touched. No `data/logs` is created.
+ *     No server process exists.
+ *
+ * So the candidate works in what looks like their editor, on their own laptop's files,
+ * and NOTHING IS RECORDED. That is the worst outcome this product has, and until this
+ * module every signal the CLI printed said it had worked.
+ *
+ * ## The two questions, and why they are both asked
+ *
+ * `seedVerdict` asks BEFORE launching: is the client's commit the one the image baked?
+ * `verifyVerdict` asks AFTER: did a server actually come up? Neither replaces the other.
+ * The first cannot be conclusive (the mirror may well serve a drifted client, and does
+ * for VS Code), and the second cannot be prompt — it costs the candidate up to a minute
+ * of waiting and, on a refusal, they have already opened a window. Asking both means the
+ * common, knowable failure is refused in advance and every other one is still loud.
+ *
+ * ## Why the probe is one shell command, and what it costs
+ *
+ * Each probe is `ssh <alias> <command>`, which sshd serves by exec'ing the candidate's
+ * login shell — so `/etc/ld.so.preload`'s `libttee.so` tees it and it lands in
+ * `candidate_activity_logs` as a `terminal_command`. That is acceptable and is NOT
+ * silent: the probe carries no pty, so `libttee`'s `tty_origin()` stamps it
+ * `origin: "tool"` (ENG-2179), which the read side groups as machinery rather than as
+ * something the candidate typed, and which the idle clock (ENG-2167) reads as a
+ * connection and never as work. It is still a row per probe, so the schedule below is
+ * deliberately sparse and backs off rather than polling on a fixed short interval.
+ */
+/** What one probe of the workspace answered. Every field is three-valued on purpose. */
+export interface WorkspaceProbe {
+    /**
+     * The server commit the IMAGE baked, from the cache pointer, or null when the pointer
+     * is absent or unreadable. Null is "we do not know", never "there is no bundle".
+     */
+    seedCommit: string | null;
+    /** How many processes the workspace is running out of this editor's server tree. */
+    serverProcesses: number;
+    /**
+     * Newest entry under `<serverHome>/data/logs`, or null when that directory does not
+     * exist. The names are timestamps (`20260915T200622`), so lexicographic order is
+     * chronological order and no `stat` is needed.
+     */
+    newestLogDir: string | null;
+}
+/**
+ * The command a probe runs in the workspace. POSIX `sh` only, and built from two
+ * constants we own — never from anything a candidate or a company supplies.
+ *
+ * Four details are load-bearing, and three of them are about one thing: `ps` output is
+ * full of near-misses, and a false POSITIVE here certifies a window that records nothing.
+ *
+ * The LEADING DOT keeps the pattern off the browser IDE — `~/.openvscode-server` contains
+ * `vscode-server` but not `/.vscode-server/`, and the browser IDE's node process is
+ * running on every healthy container, so a pattern without the dot answers "connected"
+ * for a native editor that never attached. The `[.]` bracket keeps it off the `grep` in
+ * that same listing, and the ANCHOR keeps it off everything that merely names the path.
+ * See the comments in the body for the measurements behind each.
+ *
+ * THE HOME SPELLING IS NOT THE ONLY ONE A HEALTHY CONTAINER PRODUCES, and missing the
+ * other one is silent. `litmus-firstboot.sh`'s `prewarm_editor` installs the baked bundle
+ * as a SYMLINK — `~/.<editor>-server/cli/servers/Stable-<commit>/server` ->
+ * `/opt/<editor>-server-cache/<commit>` — and the VS Code-family server bootstrap
+ * resolves its own root with `readlink -f "$0"` before exec'ing node, so on a PREWARMED
+ * (commit-matching, i.e. healthy) container argv[0] can be the `/opt` path. This repo
+ * already records both spellings for exactly these trees:
+ * `frontend/lib/server/tool-command-origin.ts`'s `SYSTEM_EDITOR_MARKERS` lists
+ * `/opt/vscode-server-cache/` and `/opt/cursor-server-cache/` beside `/.vscode-server/`.
+ * So `serverProcessPattern` carries both as alternatives, and every property above still
+ * holds of the added one: it is anchored at argv[0], so a candidate's `ls
+ * /opt/cursor-server-cache` is still not a server; it still cannot self-match, because
+ * the probe's own argv[0] is `sh` and the cache root reaches the command only as a shell
+ * VARIABLE, never as a literal followed by a slash; and unlike the home spelling that
+ * tree is root-owned on a read-only rootfs, so a candidate cannot put a binary there to
+ * forge one.
+ *
+ * WHAT IS STILL UNMEASURED, stated rather than implied: the controls behind this pattern
+ * are synthetic argv lines, taken on a laptop and not against a real prewarmed container.
+ * `ps -eo args=` on a live attached workspace, for both editors, is still to be confirmed.
+ * Adding the alternative is the safe direction in the meantime — it can only restore a
+ * signal that would otherwise be silent on the HEALTHY path, and the failure it prevents
+ * is the false alarm `verifyVerdict` names: a candidate who re-runs `litmus connect` with
+ * a window already open joins the running server, writes no new log directory, and would
+ * be told their work is not recorded.
+ *
+ * The banner is printed FIRST and unconditionally. `ssh` mixes the remote command's
+ * stdout with anything the login shell's rc files print, and a candidate's own `.bashrc`
+ * can write whatever it likes; a run that did not reach the banner is not a reading.
+ *
+ * `ps -eo args=` and not `pgrep`: procps is what the container has (the browser IDE's own
+ * monitor loop runs `ps -ax -o …`, ENG-2143), and `pgrep` is not guaranteed. A missing
+ * `ps` yields `proc 0`, which is the safe direction — it can only withhold a "connected"
+ * verdict, never manufacture one.
+ */
+/**
+ * The argv[0] pattern the probe hands `grep -E`, as ONE derivation used two ways.
+ *
+ * `remoteProbeCommand` calls it with the shell EXPRESSIONS that expand to the two names
+ * (`${d#.}` and `${c}`), so the alternation reaches the container as a pattern built from
+ * shell variables; a test calls it with the literal names and gets the ERE the container
+ * will actually run. Keeping both behind one function is what stops the anchor or the
+ * alternation being right in one form and wrong in the other.
+ */
+export declare function serverProcessPattern(serverHomeName: string, cacheRoot: string): string;
+/**
+ * The names under `<serverHome>/data/logs` this probe will consider, as an ERE.
+ *
+ * The maximum is taken lexicographically, which is chronological ONLY over timestamps —
+ * and in C collation every letter sorts above every digit, so one stray `.log`, lock file
+ * or future named subdirectory becomes the maximum forever. The direction that breaks in
+ * is the bad one: `newestLogDir` stops advancing, the log signal dies silently, and a
+ * genuinely attached editor reads as `not-connected` — the false alarm at a working
+ * candidate that the process signal exists to prevent. So the invariant the field's
+ * docstring states is ENFORCED here rather than assumed, and a directory holding nothing
+ * timestamp-shaped answers "no logs", which is a missing input.
+ *
+ * The prefix is anchored and the tail is not: a build that appends a suffix to the
+ * timestamp still sorts chronologically, while a name that does not START with one cannot
+ * poison the maximum.
+ */
+export declare const LOG_DIR_NAME_ERE = "^[0-9]{8}T[0-9]{6}";
+export declare function remoteProbeCommand(serverHomeDir: string, seedCommitPath: string): string;
+/**
+ * Read a probe's stdout. Returns null for anything that is not a complete reading —
+ * a missing banner, a missing field, a non-commit `seed` — because a partial probe that
+ * degrades into a WorkspaceProbe with plausible zeros is a probe that reports "no server
+ * is running" when what happened is that the probe did not run.
+ */
+export declare function parseWorkspaceProbe(stdout: string | null): WorkspaceProbe | null;
+/** What `<editor> --version` says about itself. */
+export interface EditorVersion {
+    version: string | null;
+    commit: string | null;
+}
+/**
+ * Read `code --version` / `cursor --version`. Both print exactly three lines — version,
+ * commit, arch — and NEITHER prints a product name (the measurement is in
+ * `NATIVE_EDITORS`' block comment in `connect.ts`, and is why identity is read off
+ * `--help` instead). The commit is found by SHAPE rather than by line number, so a build
+ * that adds a line does not silently shift which field we read; the version is the first
+ * line that is not the commit.
+ */
+export declare function parseEditorVersion(stdout: string | null): EditorVersion;
+/**
+ * Whether the client will find its own server already in the workspace.
+ *
+ * `unknown` is the answer to every missing input, and the direction that fails in is the
+ * point. We can positively assert only one thing — "these two commits are both readable
+ * and they differ" — so an unreadable `--version`, an unreachable workspace, an image
+ * with no pointer and an editor that names its build some other way may only move the
+ * answer towards "we could not tell", never towards a refusal. Refusing on a probe that
+ * failed for its own reasons would take a working editor away from a candidate on the
+ * strength of nothing; proceeding leaves them where they were before this existed, and
+ * `verifyVerdict` below is what still makes that loud.
+ */
+export type SeedVerdict = {
+    kind: "match";
+    commit: string;
+} | {
+    kind: "mismatch";
+    clientCommit: string;
+    clientVersion: string | null;
+    seedCommit: string;
+} | {
+    kind: "unknown";
+    reason: "no-client-commit" | "no-workspace-reading" | "no-seed";
+};
+export declare function seedVerdict(client: EditorVersion, probe: WorkspaceProbe | null): SeedVerdict;
+/**
+ * Did a server come up because of THIS launch?
+ *
+ * THE TWO SIGNALS ARE READ DIFFERENTLY, and which is which is the whole of this.
+ *
+ * A LOG DIRECTORY IS AN ARTIFACT ON DISK, so it must be NEW. The home mount persists
+ * across park, resume and re-provision, so `<serverHome>/data/logs` from a connection
+ * last Tuesday is still sitting there today; a verdict keyed on its mere existence
+ * answers "connected" for the exact candidate this ticket is about — one whose second
+ * `litmus connect` attaches to nothing. That is why the caller takes a BASELINE probe
+ * before launching and hands it back here.
+ *
+ * SO A MISSING BASELINE DISABLES THAT SIGNAL ENTIRELY, and reading it as "there was no
+ * log directory before" is the same false reassurance arriving by a different road. The
+ * baseline probe is one `ssh`, and every way it can fail — a flaky link, a key that
+ * wants a passphrase, a container mid-resume — answers null; a candidate who has
+ * connected to this workspace before still has last Tuesday's `data/logs` sitting in the
+ * persistent home, so a null baseline plus a dead launch would be certified "connected"
+ * on an artifact this launch did not create. A missing input may only move the answer
+ * towards "we could not tell", which is the posture every other verdict in this module
+ * already takes, so with no baseline only a RUNNING PROCESS may conclude anything and
+ * everything else is `unverified` — never `not-connected`, because we have no reading to
+ * call anything new against.
+ *
+ * And the comparison is `>` rather than `!==`: the names are timestamps, so a directory
+ * that merely CHANGED (an editor pruning its own logs, a name that sorts earlier) is not
+ * evidence that this launch wrote one.
+ *
+ * A RUNNING PROCESS IS A STATEMENT ABOUT NOW, and needs no baseline. Park is `docker
+ * stop`, so every process in the container dies with it and one that is running belongs
+ * to this container's current run — nothing stale can be seen here. Requiring it to be
+ * new as well is what an earlier cut of this did, and it is wrong in the direction that
+ * matters: a candidate who already has a window open and runs `litmus connect` again
+ * gets a second window attached to the SAME server, creating no process and no log
+ * directory, and would have been told their work was not being recorded. Telling a
+ * working candidate to abandon their editor is worse than the residual, which is narrow
+ * and named: a server already up that this particular window fails to join reads as
+ * connected. For Cursor the one known cause of that — a build mismatch — has already
+ * refused the launch before this is ever asked.
+ */
+export type VerifyVerdict = {
+    kind: "connected";
+    via: "process" | "logs";
+} | {
+    kind: "not-connected";
+} | {
+    kind: "unverified";
+};
+export declare function verifyVerdict(baseline: WorkspaceProbe | null, current: WorkspaceProbe | null): VerifyVerdict;
+/**
+ * When to probe, in milliseconds after the launch, and why it is a list rather than an
+ * interval. Every entry costs one `terminal_command` row in the candidate's own activity
+ * record (see this module's header), so the schedule spends its probes where the answer
+ * changes — a cache hit attaches in seconds — and backs off rather than paying twenty
+ * rows to shave a second off a case that was going to fail anyway. The last entry IS the
+ * budget: ~60s, which is the ticket's bound and comfortably past a warm attach.
+ */
+export declare const VERIFY_SCHEDULE_MS: readonly number[];
+//# sourceMappingURL=editor-server.d.ts.map

package/dist/lib/editor-server.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"editor-server.d.ts","sourceRoot":"","sources":["../../src/lib/editor-server.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AAEH,wFAAwF;AACxF,MAAM,WAAW,cAAc;IAC7B;;;OAGG;IACH,UAAU,EAAE,MAAM,GAAG,IAAI,CAAA;IACzB,oFAAoF;IACpF,eAAe,EAAE,MAAM,CAAA;IACvB;;;;OAIG;IACH,YAAY,EAAE,MAAM,GAAG,IAAI,CAAA;CAC5B;AAKD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH;;;;;;;;GAQG;AACH,wBAAgB,oBAAoB,CAAC,cAAc,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,MAAM,CAEtF;AAED;;;;;;;;;;;;;;;GAeG;AACH,eAAO,MAAM,gBAAgB,uBAAuB,CAAA;AAEpD,wBAAgB,kBAAkB,CAAC,aAAa,EAAE,MAAM,EAAE,cAAc,EAAE,MAAM,GAAG,MAAM,CAkDxF;AAKD;;;;;GAKG;AACH,wBAAgB,mBAAmB,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,GAAG,cAAc,GAAG,IAAI,CAwBhF;AAED,mDAAmD;AACnD,MAAM,WAAW,aAAa;IAC5B,OAAO,EAAE,MAAM,GAAG,IAAI,CAAA;IACtB,MAAM,EAAE,MAAM,GAAG,IAAI,CAAA;CACtB;AAED;;;;;;;GAOG;AACH,wBAAgB,kBAAkB,CAAC,MAAM,EAAE,MAAM,GAAG,IAAI,GAAG,aAAa,CASvE;AAED;;;;;;;;;;;GAWG;AACH,MAAM,MAAM,WAAW,GACnB;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,MAAM,EAAE,MAAM,CAAA;CAAE,GACjC;IAAE,IAAI,EAAE,UAAU,CAAC;IAAC,YAAY,EAAE,MAAM,CAAC;IAAC,aAAa,EAAE,MAAM,GAAG,IAAI,CAAC;IAAC,UAAU,EAAE,MAAM,CAAA;CAAE,GAC5F;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,MAAM,EAAE,kBAAkB,GAAG,sBAAsB,GAAG,SAAS,CAAA;CAAE,CAAA;AAExF,wBAAgB,WAAW,CAAC,MAAM,EAAE,aAAa,EAAE,KAAK,EAAE,cAAc,GAAG,IAAI,GAAG,WAAW,CAW5F;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuCG;AACH,MAAM,MAAM,aAAa,GACrB;IAAE,IAAI,EAAE,WAAW,CAAC;IAAC,GAAG,EAAE,SAAS,GAAG,MAAM,CAAA;CAAE,GAC9C;IAAE,IAAI,EAAE,eAAe,CAAA;CAAE,GACzB;IAAE,IAAI,EAAE,YAAY,CAAA;CAAE,CAAA;AAE1B,wBAAgB,aAAa,CAAC,QAAQ,EAAE,cAAc,GAAG,IAAI,EAAE,OAAO,EAAE,cAAc,GAAG,IAAI,GAAG,aAAa,CAU5G;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,kBAAkB,EAAE,SAAS,MAAM,EAA2D,CAAA"}