commandmate 0.44.2 → 0.45.0

package/dist/server/src/config/uat-isolation.js

@@ -0,0 +1,246 @@
+"use strict";
+/**
+ * `CM_UAT_ISOLATION=1` — the mode a UAT / daily-check server and its CLI run in
+ * (Issue #3360).
+ *
+ * A UAT server is isolated from production by its own port, DB, tmux socket and
+ * state directories (`.commandmate/uat.yaml`). Three paths were left that those
+ * do not cover, because they are keyed by the user's login rather than by
+ * anything the UAT can move:
+ *
+ *  1. **codex's shared files.** `$CODEX_HOME/hooks.json`, the relay under
+ *     `$CODEX_HOME/commandmate/` and the hook trust in `config.toml` live beside
+ *     codex's login (`auth.json`), so moving `CODEX_HOME` logs codex out. In this
+ *     mode the server writes none of them: it reuses the shared file only when it
+ *     is already byte-identical to what this build would write (the per-session
+ *     URL travels in the environment, so the hooks then reach THIS server), and
+ *     otherwise refuses the launch ({@link UatIsolationLaunchRefusedError}) —
+ *     a bare codex would still read the shared file and run production's hooks.
+ *     antigravity's `~/.gemini/config/hooks.json` and copilot's
+ *     `~/.copilot/settings.json` (Issue #3391) are handled the same way. It
+ *     also never answers the hook review with *trust*, which is codex writing
+ *     `config.toml`.
+ *  2. **claude's user-level hooks.** `--settings` is added to
+ *     `~/.claude/settings.json`, not substituted for it, so the user's own hooks
+ *     (which post to production) would run in a UAT session too. Moving
+ *     `CLAUDE_CONFIG_DIR` logs claude out (measured, `-p` and interactive). In
+ *     this mode claude is launched with `--setting-sources project,local`, which
+ *     drops the user source and keeps `--settings` (measured on 2.1.289) — the
+ *     interactive launch and `claude -p` (Schedules, daily summary) alike.
+ *  3. **the CLI's `.env`.** A client in this mode reads no `.env` file at all and
+ *     refuses to fall back to port 3000: it dials only the `CM_PORT` the caller
+ *     exported.
+ *
+ * Unset (or any value other than `1` / `own-home`) changes nothing anywhere.
+ *
+ * ## `CM_UAT_ISOLATION=own-home` (Issue #3312)
+ *
+ * For a run under a dedicated OS user (the daily product-path check), whose
+ * HOME holds nobody else's CLI config. Everything above still holds — the
+ * launch is refused rather than started bare when hook setup fails, the
+ * receiver URL travels in the launch environment, headless `codex exec` /
+ * `agy -p` are refused, claude reads no user-level settings, the CLI reads no
+ * `.env` and never falls back to 3000 — with one difference: the shared hook
+ * files (codex's `hooks.json`, relay and trust, antigravity's and copilot's
+ * hook files, the claude settings under `CM_AGENT_HOOKS_DIR`) are WRITTEN by
+ * this build, instead of being reused read-only. Only after
+ * {@link assertUatOwnHomeWriteTargets} has checked, before each launch, that
+ * this process runs as `CM_UAT_DEDICATED_USER`, that HOME is that user's, and
+ * that every file it is about to write resolves (symlinks followed) to a place
+ * inside that HOME owned by that user. {@link sharedHookWritePolicy} is the one
+ * rule each tool's launch path calls.
+ *
+ * `docs/user-guide/uat-isolation.md` has the measurement table and the skip
+ * conditions for what cannot be isolated.
+ *
+ * @module config/uat-isolation
+ */
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.UAT_OWN_HOME_FIX = exports.UAT_SAME_BUILD_FIX = exports.UatIsolationLaunchRefusedError = exports.CLAUDE_UAT_SETTING_SOURCES = exports.UAT_DEDICATED_USER_ENV_VAR = exports.UAT_ISOLATION_OWN_HOME = exports.UAT_ISOLATION_ENV_VAR = void 0;
+exports.getUatIsolationMode = getUatIsolationMode;
+exports.isUatIsolationEnabled = isUatIsolationEnabled;
+exports.checkUatOwnHomeWriteTargets = checkUatOwnHomeWriteTargets;
+exports.assertUatOwnHomeWriteTargets = assertUatOwnHomeWriteTargets;
+exports.sharedHookWritePolicy = sharedHookWritePolicy;
+const fs_1 = __importDefault(require("fs"));
+const os_1 = __importDefault(require("os"));
+const path_1 = __importDefault(require("path"));
+/** The switch. Only the exact values `1` and `own-home` turn it on. */
+exports.UAT_ISOLATION_ENV_VAR = 'CM_UAT_ISOLATION';
+/** The value of {@link UAT_ISOLATION_ENV_VAR} for a run under a dedicated OS user (Issue #3312). */
+exports.UAT_ISOLATION_OWN_HOME = 'own-home';
+/** The login name `own-home` must run as (Issue #3312). Compared with `os.userInfo().username`. */
+exports.UAT_DEDICATED_USER_ENV_VAR = 'CM_UAT_DEDICATED_USER';
+/**
+ * `--setting-sources` for a claude session in this mode: the user source
+ * (`$CLAUDE_CONFIG_DIR/settings.json`, hooks and plugins included) is dropped;
+ * the repository's own `project` / `local` settings and `--settings` stay.
+ */
+exports.CLAUDE_UAT_SETTING_SOURCES = 'project,local';
+/** Which isolation mode this process runs in. */
+function getUatIsolationMode(env = process.env) {
+    const value = env[exports.UAT_ISOLATION_ENV_VAR];
+    if (value === '1')
+        return 'shared-read-only';
+    if (value === exports.UAT_ISOLATION_OWN_HOME)
+        return 'own-home';
+    return 'off';
+}
+/**
+ * Whether this process runs in UAT isolation mode — `1` or `own-home`. Every
+ * protection except "never write the shared hook files" keys off this.
+ */
+function isUatIsolationEnabled(env = process.env) {
+    return getUatIsolationMode(env) !== 'off';
+}
+/**
+ * Thrown by a launch that would otherwise start an agent which reads a shared
+ * hook config this server did not (and in this mode may not) write.
+ *
+ * Starting the agent "without hooks" is not an option for codex, antigravity
+ * or copilot: the shared file is read regardless of what this server passes,
+ * so the production server's hooks — already trusted — would run in the UAT
+ * session and post to production. So the launch is refused, and the message says what
+ * makes it start.
+ */
+class UatIsolationLaunchRefusedError extends Error {
+    constructor(tool, reason, fix) {
+        super(getUatIsolationMode() === 'own-home'
+            ? `${exports.UAT_ISOLATION_ENV_VAR}=${exports.UAT_ISOLATION_OWN_HOME}: refusing to start ${tool}: ${reason}. ` +
+                `This server writes the hook config only inside the dedicated user's own HOME, and ${tool} ` +
+                `would otherwise start with hooks this server did not prepare. ${fix}`
+            : `${exports.UAT_ISOLATION_ENV_VAR}=1: refusing to start ${tool}: ${reason}. ` +
+                `This server does not write the shared hook config in UAT isolation, and ${tool} ` +
+                `would read it anyway and run the production hooks. ${fix}`);
+        this.name = 'UatIsolationLaunchRefusedError';
+    }
+}
+exports.UatIsolationLaunchRefusedError = UatIsolationLaunchRefusedError;
+/** The fix for a shared hook config that does not match this build. */
+exports.UAT_SAME_BUILD_FIX = 'Run the UAT with the same CommandMate build as the production server, so the shared file already matches what this build writes.';
+/** The fix for an `own-home` launch whose user, HOME or write targets did not check out. */
+exports.UAT_OWN_HOME_FIX = `Run ${exports.UAT_ISOLATION_ENV_VAR}=${exports.UAT_ISOLATION_OWN_HOME} as the user named by ${exports.UAT_DEDICATED_USER_ENV_VAR}, ` +
+    'with HOME set to that user\'s home and every hook config path (CODEX_HOME, CM_AGENT_HOOKS_DIR, ...) inside it.';
+function currentIdentity() {
+    const info = os_1.default.userInfo();
+    return { username: info.username, uid: info.uid, homedir: info.homedir };
+}
+/**
+ * Where a write to `target` would land, symlinks followed, and whose entry
+ * decides who may write there: the target itself when it exists, else its
+ * nearest existing ancestor (a file not yet created is judged by the directory
+ * it would be created in). A dangling symlink is refused: writing through it
+ * would create a file wherever it points.
+ */
+function resolveWriteTarget(target) {
+    const absolute = path_1.default.resolve(target);
+    let existing = absolute;
+    const rest = [];
+    for (;;) {
+        let entryExists = false;
+        try {
+            fs_1.default.lstatSync(existing);
+            entryExists = true;
+        }
+        catch {
+            entryExists = false;
+        }
+        if (entryExists)
+            break;
+        const parent = path_1.default.dirname(existing);
+        if (parent === existing)
+            return `${target} has no existing ancestor`;
+        rest.unshift(path_1.default.basename(existing));
+        existing = parent;
+    }
+    let real;
+    try {
+        real = fs_1.default.realpathSync(existing);
+    }
+    catch {
+        return `${existing} is a symlink that points nowhere`;
+    }
+    return { real: path_1.default.join(real, ...rest), owner: fs_1.default.statSync(real).uid };
+}
+/**
+ * Why an `own-home` launch may not write `writeTargets`, or null when it may
+ * (Issue #3312). Checks, in this order: `CM_UAT_DEDICATED_USER` is set and is
+ * the user this process runs as; `HOME` resolves to that user's home directory
+ * (from the account database) and is owned by them; each target resolves —
+ * every symlink on the way followed — to a path inside that home, and the entry
+ * that decides the write (the target, or its nearest existing ancestor) is
+ * owned by that user.
+ */
+function checkUatOwnHomeWriteTargets(writeTargets, env = process.env, identity = currentIdentity()) {
+    const dedicated = env[exports.UAT_DEDICATED_USER_ENV_VAR];
+    if (!dedicated)
+        return `${exports.UAT_DEDICATED_USER_ENV_VAR} is not set`;
+    if (identity.username !== dedicated) {
+        return `this process runs as ${identity.username}, not as the dedicated user ${dedicated}`;
+    }
+    const home = env.HOME;
+    if (!home || !path_1.default.isAbsolute(home))
+        return 'HOME is not set to an absolute path';
+    let homeReal;
+    let accountHomeReal;
+    try {
+        homeReal = fs_1.default.realpathSync(home);
+        accountHomeReal = fs_1.default.realpathSync(identity.homedir);
+    }
+    catch {
+        return `HOME (${home}) or ${dedicated}'s home directory (${identity.homedir}) does not exist`;
+    }
+    if (homeReal !== accountHomeReal) {
+        return `HOME (${home}) is not ${dedicated}'s home directory (${identity.homedir})`;
+    }
+    if (fs_1.default.statSync(homeReal).uid !== identity.uid)
+        return `HOME (${home}) is not owned by ${dedicated}`;
+    for (const target of writeTargets) {
+        const resolved = resolveWriteTarget(target);
+        if (typeof resolved === 'string')
+            return resolved;
+        if (resolved.real !== homeReal && !resolved.real.startsWith(`${homeReal}${path_1.default.sep}`)) {
+            return `${target} resolves to ${resolved.real}, outside ${dedicated}'s HOME (${homeReal})`;
+        }
+        if (resolved.owner !== identity.uid) {
+            return `${target} (${resolved.real}) is not owned by ${dedicated}`;
+        }
+    }
+    return null;
+}
+/**
+ * Under `own-home`, refuse the launch of `tool` unless
+ * {@link checkUatOwnHomeWriteTargets} passes for `writeTargets`. A no-op in
+ * every other mode.
+ *
+ * @throws {UatIsolationLaunchRefusedError}
+ */
+function assertUatOwnHomeWriteTargets(tool, writeTargets, env = process.env) {
+    if (getUatIsolationMode(env) !== 'own-home')
+        return;
+    const problem = checkUatOwnHomeWriteTargets(writeTargets, env);
+    if (problem)
+        throw new UatIsolationLaunchRefusedError(tool, problem, exports.UAT_OWN_HOME_FIX);
+}
+/**
+ * The one rule for a hook file shared with the user's other CommandMate
+ * servers (codex, antigravity and copilot call it; Issue #3312):
+ *
+ * - not isolated: `write`
+ * - `CM_UAT_ISOLATION=1`: `read-only` — reuse it only when it already matches
+ * - `CM_UAT_ISOLATION=own-home`: `write`, once
+ *   {@link assertUatOwnHomeWriteTargets} has passed for every path the write
+ *   touches; otherwise the launch is refused
+ *
+ * @throws {UatIsolationLaunchRefusedError} Under `own-home` only
+ */
+function sharedHookWritePolicy(tool, writeTargets, env = process.env) {
+    const mode = getUatIsolationMode(env);
+    if (mode === 'shared-read-only')
+        return 'read-only';
+    assertUatOwnHomeWriteTargets(tool, writeTargets, env);
+    return 'write';
+}

package/dist/server/src/lib/assistant-response-saver.js

@@ -53,6 +53,7 @@ var __importStar = (this && this.__importStar) || (function () {
 })();
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.detectBufferReset = detectBufferReset;
+exports.isCodexCursorAtOrBelowComposer = isCodexCursorAtOrBelowComposer;
 exports.cleanCliResponse = cleanCliResponse;
 exports.advanceCapturedLineForTranscriptTurn = advanceCapturedLineForTranscriptTurn;
 exports.savePendingAssistantResponse = savePendingAssistantResponse;
@@ -62,6 +63,7 @@ const ws_server_1 = require("./ws-server");
 // Issue #571 [DR1-05]: Import directly from response-cleaner instead of barrel re-export
 const response_cleaner_1 = require("./response-cleaner");
 const types_1 = require("./cli-tools/types");
+const cli_patterns_1 = require("./detection/cli-patterns");
 const logger_1 = require("../lib/logger");
 const logger = (0, logger_1.createLogger)('assistant-response-saver');
 /**
@@ -141,6 +143,36 @@ function countCapturedLines(output) {
     }
     return trimmedLength;
 }
+/**
+ * Does a codex cursor start at or below the composer? (Issue #3335)
+ *
+ * Nothing at or below codex's composer is a reply: it is the composer, the
+ * status bar and `? for shortcuts`. On the inline layout (0.15x) a cursor
+ * rarely lands there, because the next turn is printed over the composer band
+ * and the composer moves down. On 0.160.0 it is where the cursor always is.
+ *
+ * codex 0.160.0 draws in the alternate screen: the capture is the pane, 1000
+ * rows, whatever the transcript holds, with the composer pinned to row 996.
+ * The row count this module stores is therefore NOT a read cursor for it — it
+ * settles at 999 or 1000 after the first read (here, or in
+ * {@link advanceCapturedLineForTranscriptTurn}) and never grows again, and
+ * the reply is drawn above it. The screen read does not take codex's reply
+ * from such a pane; the reply reaches History from codex's own transcript
+ * (`hooks/sources/codex/history.ts`). What this rule stops is the flush
+ * saving the chrome past the parked cursor as the reply — before #3335 a
+ * cursor of 999 saved `? for shortcuts`, and 997 or 998 the status bar.
+ *
+ * The composer is located by its SGR attributes (#2310), on the whole pane.
+ * A pane it cannot be found on keeps the reading it had.
+ *
+ * @param lines - The whole capture, ANSI intact
+ * @param cursor - The row the flush would start reading at
+ * @returns True when the rows from `cursor` down are all codex chrome
+ */
+function isCodexCursorAtOrBelowComposer(lines, cursor) {
+    const chromeStart = (0, cli_patterns_1.findCodexChromeStart)(lines);
+    return chromeStart >= 0 && cursor >= chromeStart;
+}
 /**
  * Time offset (in milliseconds) for assistant message timestamp
  * Ensures assistant response appears before user message in chronological order
@@ -167,9 +199,12 @@ const ASSISTANT_TIMESTAMP_OFFSET_MS = 1;
  *
  * @param output - Raw output from CLI tool
  * @param cliToolId - CLI tool identifier
+ * @param paneLines - The whole capture `output` was sliced from, for the
+ *   startup-screen rule of {@link cleanScrollbackResponse} (Issue #3293). Only
+ *   that cleaner reads it; omitted, no tool's cleaning changes
  * @returns Cleaned response content
  */
-function cleanCliResponse(output, cliToolId) {
+function cleanCliResponse(output, cliToolId, paneLines) {
     switch (cliToolId) {
         case 'claude':
             return (0, response_cleaner_1.cleanClaudeResponse)(output);
@@ -183,7 +218,7 @@ function cleanCliResponse(output, cliToolId) {
         case 'command-code':
         case 'antigravity':
         case 'vibe-local':
-            return (0, response_cleaner_1.cleanScrollbackResponse)(output, cliToolId);
+            return (0, response_cleaner_1.cleanScrollbackResponse)(output, cliToolId, paneLines);
         default:
             return output.trim();
     }
@@ -362,7 +397,31 @@ async function savePendingAssistantResponse(db, worktreeId, cliToolId, userMessa
         // 8. Clean the response.
         // Only scrollback-rendering tools reach this point (Issue #1292), so the
         // tool-specific cleaners in cleanCliResponse cover every remaining case.
-        const cleanedResponse = cleanCliResponse(newOutput, cliToolId);
+        //
+        // Issue #3293: the pane goes with the rows. On the first send of a session
+        // the cursor is 0 and "everything past it" is the tool's startup screen —
+        // measured on vibe-local as `response:saved {"fromLine":0,"toLine":1001}`
+        // 30 ms after `started-vibe-local-session`, and on codex as an assistant
+        // row holding the version, the cwd and the logo. A pane no message has been
+        // echoed on yet holds no reply, and that is a fact about the pane: the rows
+        // past the cursor ordinarily carry no echo either. It cleans to '', so the
+        // branch below moves the cursor exactly as the banner save used to.
+        //
+        // Not on a capture that came back at the size it was asked for: the window
+        // has clipped it, and the echo of a turn longer than the window is no longer
+        // in it. This is `isCaptureWindowSaturated` (#1670) against this module's
+        // own window, written out because `lib/tmux` is not imported from here
+        // (#1922).
+        const captureClipped = lines.length >= SESSION_OUTPUT_BUFFER_SIZE;
+        //
+        // Issue #3335: on codex, rows from the composer down are chrome, never a
+        // reply — and on 0.160.0 (alternate screen) that is where the cursor
+        // parks for the life of the session. Read as nothing, so the branch below
+        // moves the cursor as an empty clean would. See isCodexCursorAtOrBelowComposer.
+        const pastCodexComposer = cliToolId === 'codex' && isCodexCursorAtOrBelowComposer(lines, effectiveLastCapturedLine);
+        const cleanedResponse = pastCodexComposer
+            ? ''
+            : cleanCliResponse(newOutput, cliToolId, captureClipped ? undefined : lines);
         // 9. Check if cleaned response is empty
         if (!cleanedResponse || cleanedResponse.trim() === '') {
             // Output exists but cleaned to empty - update position but don't save

package/dist/server/src/lib/auto-yes-lifecycle.js

@@ -49,6 +49,12 @@ const auto_yes_manager_1 = require("./polling/auto-yes-manager");
  * reason (no new reason was added), for the instance only. `server-shutdown`
  * deliberately does not persist anything: the state lives in memory, and a
  * restarted server starting with every grant off is the safe side.
+ *
+ * `consecutive-errors` is for real capture failures only: a session that
+ * exists but cannot be read. A session that does not exist (not started yet,
+ * or not started at all) is not one — the poller waits for it until
+ * `expiresAt`, at the backoff cap (Issue #3329), since the grant is
+ * independent of the session.
  */
 exports.AUTO_YES_LIFECYCLE = {
     'session-killed': { state: 'disable', poller: 'stop' },