commandmate 0.29.1 → 0.29.2

package/dist/server/src/config/codex-update-dialog-config.js

@@ -0,0 +1,154 @@
+"use strict";
+/**
+ * What CommandMate answers when codex offers to update itself (Issue #2068).
+ *
+ * codex checks for a new release before its TUI opens and, once
+ * `$CODEX_HOME/version.json` has a `latest_version` cached, puts a numbered
+ * dialog in front of the session:
+ *
+ * ```
+ *   ✨ Update available! 0.149.1 -> 0.151.0
+ *   Release notes: https://github.com/openai/codex/releases/latest
+ * › 1. Update now (runs `npm install -g @openai/codex`)
+ *   2. Skip
+ *   3. Skip until next version
+ *   Press enter to continue
+ * ```
+ *
+ * `CodexTool.waitForReady` has answered it with `'2'` since Issue #890, for the
+ * good reason that `'1'` replaces codex with `npm install` and exits. The cost
+ * was only measured for this Issue: **`'2'` persists nothing.** Measured on
+ * codex-cli 0.149.1 in an isolated `CODEX_HOME` (2026-08-31) —
+ *
+ * | key | `version.json` after | next launch |
+ * |-----|----------------------|-------------|
+ * | `'2'` | `dismissed_version: null` (unchanged) | dialog again |
+ * | `'3'` | `dismissed_version: "0.151.0"` | **no dialog** |
+ * | `'1'` | unchanged; codex exits into `npm install -g @openai/codex` | — |
+ *
+ * — so every single session start met the dialog, spent a poll answering it,
+ * and the operator could never choose the update because the server always
+ * chose for them. Hence a policy rather than a constant.
+ *
+ * ## Why the default moved to `'3'` and not to `'1'`
+ *
+ * `skip-until-next-version` is the only one of the three that is both
+ * non-destructive and *idempotent*: it writes the version the operator has
+ * already been told about into `dismissed_version`, so the dialog returns when —
+ * and only when — there is something new to say. `update` stays opt-in because
+ * it kills the agent mid-launch (recovered here, but still a restart nobody
+ * asked for) and because upgrading the operator's own global npm package is not
+ * a decision a session start gets to make silently.
+ *
+ * @module config/codex-update-dialog-config
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.CODEX_UPDATE_DIALOG_KEYS = exports.CODEX_UPDATE_DIALOG_ENV_VAR = exports.DEFAULT_CODEX_UPDATE_DIALOG_POLICY = exports.CODEX_UPDATE_DIALOG_POLICIES = void 0;
+exports.isCodexUpdateDialogPolicy = isCodexUpdateDialogPolicy;
+exports.normalizeCodexUpdateDialogPolicy = normalizeCodexUpdateDialogPolicy;
+exports.resolveCodexUpdateDialogPolicy = resolveCodexUpdateDialogPolicy;
+exports.codexUpdateDialogAnswerKey = codexUpdateDialogAnswerKey;
+/** Every accepted value, in the order the documentation lists them. */
+exports.CODEX_UPDATE_DIALOG_POLICIES = [
+    'skip',
+    'skip-until-next-version',
+    'update',
+    'ask',
+];
+/**
+ * The default, and the answer to "why is this not `skip`".
+ *
+ * See the measurement table in the module comment: `skip` is the value that
+ * produced the reported bug, and it produced it on every launch.
+ */
+exports.DEFAULT_CODEX_UPDATE_DIALOG_POLICY = 'skip-until-next-version';
+/** Operator override, read from the server's own environment. */
+exports.CODEX_UPDATE_DIALOG_ENV_VAR = 'CM_CODEX_UPDATE_DIALOG';
+/**
+ * The key each policy sends, or `null` when nobody may answer for the human.
+ *
+ * `satisfies` rather than an annotation, so the table is exhaustive over
+ * {@link CodexUpdateDialogPolicy} (a policy added without an answer is a
+ * compile error) AND each entry keeps its literal type. The second half is load
+ * bearing: `CodexTool.waitForReady` reads
+ * `CODEX_UPDATE_DIALOG_KEYS['skip-until-next-version']` as its fallback when
+ * #2069's update lock is already held, and an annotation would widen that to
+ * include `null` — the one value that branch must never send.
+ *
+ * The digits are codex's own option numbers and they are sent ALONE — codex
+ * confirms a numbered selection instantly and a trailing Enter lands on the
+ * next screen (Issue #890, re-measured for this Issue: `'3'` alone took the
+ * pane straight to `› Ask Codex to do anything`).
+ */
+exports.CODEX_UPDATE_DIALOG_KEYS = Object.freeze({
+    update: '1',
+    skip: '2',
+    'skip-until-next-version': '3',
+    ask: null,
+});
+/**
+ * Whether a value names a policy.
+ *
+ * @param value - Candidate, from anywhere
+ * @returns True when `value` is one of {@link CODEX_UPDATE_DIALOG_POLICIES}
+ */
+function isCodexUpdateDialogPolicy(value) {
+    return (typeof value === 'string' &&
+        exports.CODEX_UPDATE_DIALOG_POLICIES.includes(value));
+}
+/**
+ * Coerce an untrusted value into a policy, or `null` when it names none.
+ *
+ * Case- and whitespace-insensitive, because the value arrives from a shell
+ * export and `CM_CODEX_UPDATE_DIALOG=Update ` is what an operator types.
+ * Anything unrecognised becomes `null` rather than a guess: the caller then
+ * falls back to the default, which is the safe answer, instead of acting on a
+ * typo that might mean `update`.
+ *
+ * @param value - Candidate, from the environment or a stored setting
+ * @returns The policy, or null
+ */
+function normalizeCodexUpdateDialogPolicy(value) {
+    if (typeof value !== 'string')
+        return null;
+    const normalized = value.trim().toLowerCase();
+    return isCodexUpdateDialogPolicy(normalized) ? normalized : null;
+}
+/**
+ * The policy a codex session start acts on.
+ *
+ * Precedence: the instance's own setting, then the server environment, then
+ * {@link DEFAULT_CODEX_UPDATE_DIALOG_POLICY}. `instanceSetting` is a parameter
+ * rather than a lookup so this module stays free of `better-sqlite3` — and so
+ * that the per-instance store, when it lands, has one place to plug into
+ * instead of a second resolution order of its own. Nothing persists a
+ * per-instance value yet (that needs an `agent_instances` column and a route,
+ * neither of which is in this Issue's diff), so today the effective order is
+ * environment, then default.
+ *
+ * @param options.instanceSetting - The instance's stored value, if any
+ * @param options.env - Environment to read (defaults to `process.env`). Typed
+ *   as a plain string map rather than `NodeJS.ProcessEnv` so a caller — a test,
+ *   most of all — can pass a literal without having to satisfy the `NODE_ENV`
+ *   that Next's own augmentation makes mandatory.
+ * @returns The policy to act on; never null
+ */
+function resolveCodexUpdateDialogPolicy(options) {
+    const fromInstance = normalizeCodexUpdateDialogPolicy(options?.instanceSetting);
+    if (fromInstance !== null)
+        return fromInstance;
+    const env = options?.env ?? process.env;
+    const fromEnv = normalizeCodexUpdateDialogPolicy(env[exports.CODEX_UPDATE_DIALOG_ENV_VAR]);
+    if (fromEnv !== null)
+        return fromEnv;
+    return exports.DEFAULT_CODEX_UPDATE_DIALOG_POLICY;
+}
+/**
+ * The key {@link resolveCodexUpdateDialogPolicy}'s answer sends.
+ *
+ * @param policy - The resolved policy
+ * @returns `'1'` / `'2'` / `'3'`, or null when the human owns the screen
+ */
+function codexUpdateDialogAnswerKey(policy) {
+    return exports.CODEX_UPDATE_DIALOG_KEYS[policy];
+}

package/dist/server/src/config/default-agents.js

@@ -0,0 +1,138 @@
+"use strict";
+/**
+ * Client-side mirror of the server's default agent list (Issue #2065).
+ *
+ * ## Why a module store rather than a prop or a context
+ *
+ * Before #2065 the client's fallback for "this worktree has no `selectedAgents`"
+ * was the imported constant `DEFAULT_SELECTED_AGENTS`, read from module scope at
+ * EIGHT sites (`grep -rn 'DEFAULT_SELECTED_AGENTS' src/`) — two of them inside
+ * `deriveSidebarCliStatus()`, a PURE function that receives one `Worktree` and
+ * nothing else, and four inside `useState` initializers that run before any
+ * fetch has resolved. Neither shape can consume a React context or a prop
+ * without rewriting its callers, so the smallest honest change is to keep the
+ * read at module scope and make the module scope itself configurable.
+ *
+ * The store starts at the compiled-in constant, so a page that never seeds it
+ * behaves exactly as it did before this Issue.
+ *
+ * ## What it is not
+ *
+ * It is NOT the authority. The server resolves `selectedAgents` for every
+ * worktree it sends (`parseSelectedAgents` + `app_settings`), so these fallbacks
+ * only fire for a payload that omits the field — an older response, a test
+ * fixture, or the moment before the first fetch lands. Seeding this store makes
+ * that moment agree with the server instead of disagreeing with it.
+ *
+ * ## Freshness
+ *
+ * Reads are synchronous and non-reactive: a component that reads the store does
+ * not re-render when it changes. Every screen that reads it polls (`/sessions`,
+ * `/review`, the worktree detail controller), so a change is visible on the next
+ * poll tick, and `subscribe()` is available for a surface that needs it sooner.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.DEFAULT_AGENTS_ENDPOINT = void 0;
+exports.getClientDefaultSelectedAgents = getClientDefaultSelectedAgents;
+exports.setClientDefaultSelectedAgents = setClientDefaultSelectedAgents;
+exports.resetClientDefaultSelectedAgents = resetClientDefaultSelectedAgents;
+exports.subscribeToClientDefaultSelectedAgents = subscribeToClientDefaultSelectedAgents;
+exports.ensureClientDefaultSelectedAgents = ensureClientDefaultSelectedAgents;
+const selected_agents_validator_1 = require("../lib/selected-agents-validator");
+/** Where the client asks for the server-wide default. */
+exports.DEFAULT_AGENTS_ENDPOINT = '/api/settings/default-agents';
+let current = selected_agents_validator_1.DEFAULT_SELECTED_AGENTS;
+const listeners = new Set();
+/**
+ * The agent list to fall back to when a worktree payload carries no
+ * `selectedAgents`. Ordered; `[0]` is the primary.
+ */
+function getClientDefaultSelectedAgents() {
+    return current;
+}
+/**
+ * Adopt a default sent by the server.
+ *
+ * Validated here rather than trusted, for the same reason the DB read is:
+ * whatever ships this value (a settings GET, a `/api/worktrees` payload, a save
+ * response) is one JSON field away from being wrong, and a malformed value must
+ * leave the previous answer standing rather than blank the tab strip.
+ *
+ * @param value - Candidate list from a server response
+ * @returns true when the store changed
+ */
+function setClientDefaultSelectedAgents(value) {
+    if (!Array.isArray(value))
+        return false;
+    const result = (0, selected_agents_validator_1.validateAgentsPair)(value);
+    if (!result.valid)
+        return false;
+    const next = result.value;
+    if (next.length === current.length && next.every((id, i) => id === current[i])) {
+        return false;
+    }
+    current = next;
+    for (const listener of listeners)
+        listener();
+    return true;
+}
+/** Return the store to the compiled-in constant. Used by tests and by a reset. */
+function resetClientDefaultSelectedAgents() {
+    const changed = current !== selected_agents_validator_1.DEFAULT_SELECTED_AGENTS;
+    current = selected_agents_validator_1.DEFAULT_SELECTED_AGENTS;
+    if (changed) {
+        for (const listener of listeners)
+            listener();
+    }
+    inFlight = null;
+    seeded = false;
+}
+/** Subscribe to store changes. Returns an unsubscribe function. */
+function subscribeToClientDefaultSelectedAgents(listener) {
+    listeners.add(listener);
+    return () => {
+        listeners.delete(listener);
+    };
+}
+let inFlight = null;
+let seeded = false;
+/**
+ * Seed the store from the server, at most once per page session.
+ *
+ * Single-flight and idempotent: `/sessions`, `/review` and the worktree detail
+ * controller all call it on mount and a route change between them must not
+ * produce a second request. Failures are swallowed — the constant is a correct
+ * answer, and a settings fetch is never a reason to break a screen.
+ *
+ * Deliberately hits the settings route and not `/api/worktrees`: this is called
+ * from mount effects on screens that may not fetch the worktree list at all, and
+ * the settings route is a single point query with no tmux work behind it.
+ *
+ * @returns The default in force after the attempt
+ */
+async function ensureClientDefaultSelectedAgents() {
+    if (seeded)
+        return current;
+    if (inFlight)
+        return inFlight;
+    if (typeof fetch !== 'function')
+        return current;
+    inFlight = (async () => {
+        try {
+            const response = await fetch(exports.DEFAULT_AGENTS_ENDPOINT);
+            if (response.ok) {
+                const body = await response.json();
+                setClientDefaultSelectedAgents(body?.defaultSelectedAgents);
+                seeded = true;
+            }
+        }
+        catch {
+            // Offline / server restarting: keep whatever the store already holds.
+        }
+        finally {
+            inFlight = null;
+        }
+        return current;
+    })();
+    return inFlight;
+}

package/dist/server/src/lib/cli-tools/antigravity.js

@@ -116,25 +116,43 @@ class AntigravityTool extends base_1.BaseCLITool {
         const exists = await (0, tmux_1.hasSession)(sessionName);
         if (exists) {
             await this.reconcileExistingSession(sessionName);
-            logger.info('antigravity-session-exists');
-            return;
+            // Issue #2070: this branch used to return unconditionally. A tmux session
+            // outlives the agent that was launched into it — a quit, a self-update, a
+            // crash — and the launch was then skipped for a pane holding nothing but a
+            // shell prompt, which left `kill-session` by hand as the only recovery.
+            // When the tool is gone we fall THROUGH and re-send the launch command
+            // into the same pane.
+            if (await this.isToolLive(sessionName, { confirm: true })) {
+                logger.info('antigravity-session-exists');
+                return;
+            }
+            logger.warn('antigravity-session-relaunch', { sessionName });
         }
         // Issue #1762: fence this instance's structured events off from the process
         // that used to hold the same (worktree, tool, instance) key. Creation path
         // only — the reuse branch above has already returned — and before the pane
         // exists. Bumped even if the launch below then fails.
+        //
+        // Issue #2070: reached on the RELAUNCH path too — the pane is the same one,
+        // but the process is not, and the dead process's events must not be read as
+        // the new one's.
         (0, agent_session_lifecycle_1.beginAgentSession)({ worktreeId, cliToolId: sources_1.ANTIGRAVITY_CLI_TOOL_ID, instanceId });
         try {
-            // Create tmux session with large history buffer for agy output
-            // (agy is inline-rendered and retains scrollback, like Codex)
-            // Scrollback depth comes from the shared TMUX_HISTORY_LIMIT default
-            // (Issue #1624) — do not re-hardcode it here.
-            await (0, tmux_1.createSession)({
-                sessionName,
-                workingDirectory: worktreePath,
-            });
-            // Wait a moment for the session to be created
-            await new Promise((resolve) => setTimeout(resolve, cli_tool_timing_config_1.TUI_SESSION_CREATE_WAIT_MS));
+            // Issue #2070: creation only. On the relaunch path the pane already
+            // exists and holds the transcript of the process that died in it; the
+            // launch command is re-sent into that same pane.
+            if (!exists) {
+                // Create tmux session with large history buffer for agy output
+                // (agy is inline-rendered and retains scrollback, like Codex)
+                // Scrollback depth comes from the shared TMUX_HISTORY_LIMIT default
+                // (Issue #1624) — do not re-hardcode it here.
+                await (0, tmux_1.createSession)({
+                    sessionName,
+                    workingDirectory: worktreePath,
+                });
+                // Wait a moment for the session to be created
+                await new Promise((resolve) => setTimeout(resolve, cli_tool_timing_config_1.TUI_SESSION_CREATE_WAIT_MS));
+            }
             // Start agy in interactive mode, optionally pinned to a model.
             //
             // Issue #1762: the launch merges CommandMate's named hook into
@@ -237,6 +255,12 @@ class AntigravityTool extends base_1.BaseCLITool {
         if (!exists) {
             throw new Error(`Antigravity session ${sessionName} does not exist. Start the session first.`);
         }
+        // Issue #2070: the pane exists, but does the AGENT? An agent that quit,
+        // updated itself or crashed leaves its tmux session behind, and the send
+        // that followed used to sit in the readiness wait until it timed out —
+        // leaving `kill-session` by hand as the only recovery. Relaunches into the
+        // same pane when the tool is gone; costs one `capture-pane` when it is not.
+        await this.relaunchIfToolExited(worktreeId, instanceId);
         try {
             // Verify agy is at a ready prompt before sending
             await this.waitForPrompt(sessionName);

package/dist/server/src/lib/cli-tools/base.js

@@ -12,9 +12,14 @@ const tmux_1 = require("../tmux/tmux");
 const composer_spec_1 = require("./composer-spec");
 const capture_spec_1 = require("./capture-spec");
 const graceful_exit_1 = require("./graceful-exit");
+const liveness_spec_1 = require("./liveness-spec");
+const session_liveness_1 = require("./session-liveness");
 const start_availability_1 = require("./start-availability");
+const logger_1 = require("../logger");
 const terminal_keys_1 = require("../../types/terminal-keys");
+const cli_tool_timing_config_1 = require("../../config/cli-tool-timing-config");
 const execAsync = (0, util_1.promisify)(child_process_1.exec);
+const logger = (0, logger_1.createLogger)('cli-tools/base');
 /**
  * Abstract base class for CLI tools
  * Implements common functionality and defines abstract methods for specific implementations
@@ -155,6 +160,132 @@ class BaseCLITool {
     captureSpec() {
         return (0, capture_spec_1.resolveCaptureSpec)(this.id);
     }
+    /**
+     * Describe how this tool's pane is read for "did the TOOL exit?"
+     * (Issue #2070).
+     *
+     * Answered from `./liveness-spec`, the §4 D4 shape every other `describe…` /
+     * `…Spec` method on this class takes. A tool overrides it only if its pane
+     * needs a rule the table cannot express.
+     *
+     * @returns This tool's {@link ToolLivenessSpec}
+     */
+    livenessSpec() {
+        return (0, liveness_spec_1.resolveLivenessSpec)(this.id);
+    }
+    /**
+     * Whether this tool is still the thing drawing `sessionName`'s pane
+     * (Issue #2070).
+     *
+     * Two callers. The reuse branch of every `launchSession`, where a `false`
+     * means the launch command has to be re-sent into the pane instead of the
+     * branch returning as if nothing were wrong; and
+     * {@link relaunchIfToolExited}, which is how a `sendMessage` finds out that
+     * there is nothing to type into. Deliberately NOT `isRunning` — see that
+     * method's docblock for the three callers that read `isRunning` as "does the
+     * pane exist?".
+     *
+     * ## Why the reuse branch confirms twice
+     *
+     * `confirm: true` re-reads the pane after {@link LIVENESS_CONFIRM_DELAY_MS}
+     * and requires BOTH readings to say the tool is gone. There is a window in
+     * which a pane legitimately shows a bare shell and nothing else: between
+     * `createSession` and the launch line landing, i.e. exactly when a second
+     * `startSession` for the same worktree can arrive. One reading cannot tell
+     * that window from a dead session, and getting it wrong types a launch
+     * command into a live agent's composer. Two readings a second apart can: a
+     * booting pane has painted by the second one.
+     *
+     * The status poll (`worktree-status-helper`) does NOT confirm — it publishes a
+     * dot, and a dot that is briefly wrong during a launch is the pre-existing
+     * behaviour of claude's own health check. Nothing is relaunched off it.
+     *
+     * @param sessionName - tmux session name
+     * @param options.confirm - Re-read once before returning false
+     * @returns True when the tool is (or may still be) there
+     */
+    async isToolLive(sessionName, options) {
+        const spec = this.livenessSpec();
+        const first = await (0, session_liveness_1.probeSessionLiveness)(sessionName, spec);
+        if (first.alive)
+            return true;
+        if (!options?.confirm)
+            return false;
+        await new Promise((resolve) => setTimeout(resolve, cli_tool_timing_config_1.LIVENESS_CONFIRM_DELAY_MS));
+        const second = await (0, session_liveness_1.probeSessionLiveness)(sessionName, spec);
+        if (second.alive) {
+            logger.info('session:liveness-confirm-recovered', {
+                cliToolId: this.id,
+                firstReason: first.reason,
+            });
+            return true;
+        }
+        logger.warn('session:tool-exited', { cliToolId: this.id, reason: second.reason });
+        return false;
+    }
+    /**
+     * Relaunch this tool if its pane has fallen back to the shell, so the send
+     * about to happen has an agent to reach (Issue #2070).
+     *
+     * ## Why this is in `sendMessage` and not in `isRunning`
+     *
+     * `isRunning` is the natural place — it is what `POST .../send` consults
+     * before deciding to start a session, and `isClaudeRunning` has folded a
+     * health check into it since MF-S3-001. Measured against the callers, though,
+     * `isRunning` is load-bearing as **"does the pane exist?"** for three of them,
+     * and narrowing it would break all three:
+     *
+     *   - `POST .../terminal` calls it and says so in a comment — "the ICLITool
+     *     spelling of the `hasSession` check this used to make directly". A false
+     *     there 404s the terminal view for the very pane the operator wants to
+     *     look at to see what happened;
+     *   - `POST .../kill-session` skips any target whose `isRunning` is false, so
+     *     Stop would silently do nothing on a dead-tool pane;
+     *   - `killWorktreeSession` (repository delete / sync cleanup) does the same,
+     *     leaking the tmux session.
+     *
+     * (All three are already true of claude, and have been since MF-S3-001. This
+     * Issue does not make them worse; a widened `isRunning` would have made them
+     * seven times as likely to be hit. Giving `ICLITool` a separate
+     * "does the pane exist?" verb and moving those three onto it is the right
+     * repair, and it is a change to `src/app/api/**` and `src/lib/session-cleanup.ts`,
+     * which is a different Issue's diff.)
+     *
+     * So the recovery hangs off the send instead, where the question really is
+     * "is there an agent to type into?" — and it reuses {@link startSession}, so
+     * the relaunch is the same one the explicit start path takes, including the
+     * two-reading confirmation and the event-generation fence.
+     *
+     * Fails open in every branch: a live tool costs one `capture-pane`, and a
+     * pane whose directory tmux cannot report falls through to the pre-#2070
+     * behaviour (the send proceeds and the tool's own readiness wait reports the
+     * failure). A tool that IS gone pays the confirmation delay once, inside
+     * `launchSession`.
+     *
+     * @param worktreeId - Worktree ID
+     * @param instanceId - Agent instance ID (defaults to the primary instance)
+     */
+    async relaunchIfToolExited(worktreeId, instanceId) {
+        const sessionName = this.getSessionName(worktreeId, instanceId);
+        // One reading, not two. This is a cheap filter, not the decision: the
+        // authoritative gate is the confirmed check inside `launchSession`'s reuse
+        // branch, which runs a moment later and refuses to relaunch a pane that has
+        // painted in between. Confirming here as well would put two seconds in front
+        // of every recovery and buy nothing.
+        if (await this.isToolLive(sessionName))
+            return;
+        // The pane's own directory, not the worktree row's. `sendMessage` is not
+        // given a path, and asking tmux is both simpler than a DB lookup and more
+        // truthful: it is the directory the relaunched agent will actually run in,
+        // whatever the database now says about a worktree that may have moved.
+        const worktreePath = await (0, tmux_1.getSessionWorkingDirectory)(sessionName);
+        if (worktreePath === null) {
+            logger.warn('session:relaunch-skipped-no-path', { cliToolId: this.id, worktreeId });
+            return;
+        }
+        logger.info('session:relaunch-before-send', { cliToolId: this.id, sessionName });
+        await this.startSession(worktreeId, worktreePath, instanceId);
+    }
     /**
      * Declare the keys this tool's terminal UI may send (Issue #2046).
      *