@phnx-labs/agents-cli 1.22.120 → 1.22.121

package/dist/lib/computer/record.js

@@ -1,59 +1,14 @@
-/**
- * record.ts — turn the engine's NDJSON action events into agents-cli's own
- * records: a feed event and a row in the computer-session history that
- * `agents computer sessions` and `agents sessions --computer` read.
- *
- * WHY THIS STAYS HERE. The feed, the actor registry, and `sessions.db` are
- * agents-cli state. Handing the standalone engine a writer for all three would
- * have made it a second author of the session index — precisely the
- * "one engine, one executor" rule the repo holds elsewhere. Instead the engine
- * reports what it did on fd 4 and agents-cli, which owns those stores, records it.
- *
- * Before PHNX-4075 this was `emitComputerAction`, called inline by each verb in
- * the same process. The behavior is unchanged; only the trigger moved from a
- * function call to a line on a pipe.
- *
- * WHAT THE ENGINE OWNS, AND IS NOT REWRITTEN HERE: the action's identity. The
- * engine mints the `invocationId` that groups a whole run into one session row,
- * names the `host` it drove, and echoes back the session/launch/actor it was
- * handed. Re-deriving any of those from this process would describe the CLI that
- * spawned the engine rather than the run that happened — and for `--device` the
- * two genuinely differ.
- */
 import { randomUUID } from 'node:crypto';
 import { emit as emitEvent } from '../feed/events.js';
 import { recordComputerSession } from '../session/db.js';
 import { resolveActor } from '../actor.js';
 import { truncate } from '../feed/events.js';
 import { TASK_PREVIEW_MAX_CHARS } from './sessions-list.js';
-/**
- * Fallback grouping id for an engine that reported no `invocationId` of its own.
- * One per `agents computer` process, so such a run still collapses to a single
- * session row instead of N unrelated ones.
- */
 export const COMPUTER_INVOCATION_ID = randomUUID();
-/**
- * Record one action the engine performed. Never throws: the action already
- * happened and already reported its own success or failure on the engine's
- * stderr, so a bookkeeping failure must not turn a successful click into a
- * failed command.
- */
 export function recordComputerAction(event, opts = {}) {
-    const { event: _kind, command, invocationId, 
-    // The ledger's `pid` is the EMITTING process's by construction (events.ts
-    // stamps `process.pid` over any payload value), so the engine's own pid
-    // cannot be carried in it. Dropped rather than passed in to be silently
-    // overwritten.
-    pid: _enginePid, host, sessionId, launchId, actor, ...rest } = event;
+    const { event: _kind, command, invocationId, pid: _enginePid, host, sessionId, launchId, actor, ...rest } = event;
     const runId = invocationId || COMPUTER_INVOCATION_ID;
-    // The driven machine. `host` is the field `sessions-list.ts` reads for a
-    // remote run; `opts.device` is the fallback for an engine that drove the
-    // device this CLI resolved but did not stamp it.
     const drivenHost = host ?? opts.device;
-    // The task preview is bounded HERE, not upstream. agents-cli owns the ledger
-    // and therefore its retention/privacy rule (see sessions-list.ts): an engine
-    // that reported a full `--task` string must not be able to write an unbounded
-    // one into the session index.
     const extra = typeof rest.task === 'string'
         ? { ...rest, task: truncate(rest.task, TASK_PREVIEW_MAX_CHARS) }
         : rest;
@@ -68,7 +23,6 @@ export function recordComputerAction(event, opts = {}) {
         });
     }
     catch {
-        // Feed emission is best-effort; the action is already done.
     }
     try {
         recordComputerSession({
@@ -81,6 +35,5 @@ export function recordComputerAction(event, opts = {}) {
         });
     }
     catch {
-        // Recording is best-effort; the action and its event are already done.
     }
 }

package/dist/lib/computer/sessions-list.d.ts

@@ -1,40 +1,20 @@
-import type { SessionMeta } from '../session/types.js';
-/** Max chars of a `run --task` description persisted to the ledger — see the
- *  module docblock's retention/privacy note. */
+import type { SessionMeta } from '@phnx-labs/sessions-cli/reader';
 export declare const TASK_PREVIEW_MAX_CHARS = 200;
-/** One `computer.action` ledger entry, narrowed to the fields this module
- *  renders or groups by. */
 export interface ComputerAction {
-    /** CLI verb: `click`, `type`, `screenshot`, … or `run` for the task marker
-     *  `registerRunCommand` emits before entering the model loop. */
     verb: string;
     ts: string;
     tsMs: number;
-    /** The emitting CLI process's own pid — the run/task grouping key. */
     pid: number;
-    /** Unique for the emitting CLI process; absent only on legacy ledger rows. */
     invocationId?: string;
-    /** The driven app's pid, when resolved. */
     targetPid?: number;
     bundle?: string;
-    /** `--device <device>` target when this action drove a remote daemon. */
     host?: string;
-    /** Truncated `--task` text; only ever present on a `verb: 'run'` marker. */
     task?: string;
     sessionId?: string;
     launchId?: string;
     agent?: string;
     machineId?: string;
     hostname?: string;
-    /**
-     * The file a successful `screenshot` action actually wrote.
-     *
-     * Recorded by the standalone engine only AFTER the write succeeded, so its
-     * presence is proof the file existed — which is why nothing here ever derives
-     * a path from the verb. An action from before the producer carried this field
-     * has no capture, and that is reported honestly as none rather than guessed at
-     * from an output flag that may never have been written.
-     */
     capture?: {
         path: string;
         kind: 'screenshot';
@@ -42,163 +22,56 @@ export interface ComputerAction {
         bytes?: number;
     };
 }
-/**
- * The standalone engine's OWN action ledger.
- *
- * `agents computer` is a thin consumer of the standalone `computer` engine
- * (PHNX-4075), and that engine ALWAYS appends every action it performs to
- * `<cache>/computer/actions/<day>.jsonl` — independently of whether agents-cli
- * was in the call at all. So a `computer` command the operator ran directly
- * appears ONLY here: it never reached `recordComputerAction`, so it is in
- * neither the feed event ledger nor `computer_sessions`. Reading only those two
- * meant the actions an operator actually performed were invisible to every
- * agents-cli surface.
- */
 export declare function standaloneComputerActionsDir(): string;
-/**
- * Read the standalone ledger, newest day first, bounded by `limit` actions.
- *
- * Bounded by construction: days are read newest-first and reading stops as soon
- * as the budget is met, so a box with months of history costs the same as one
- * with a day of it.
- */
 export declare function listStandaloneComputerActions(opts?: {
     limit?: number;
     dir?: string;
     observer?: string;
 }): ComputerAction[];
-/**
- * Union the two ledgers, preferring the standalone record for any run present in
- * both.
- *
- * Dedupe keys on `invocationId`, NOT on a timestamp or pid. When a command is
- * forwarded through `agents computer`, BOTH stores receive it — and the
- * forwarding rewrites `ts` and `pid` on the way through, so the two copies of one
- * action do not agree on either. `invocationId` is minted by the engine and
- * echoed unchanged, which makes it the only field that identifies the same run in
- * both files. A legacy feed record with no invocationId cannot be matched to
- * anything, so it is kept: dropping it would lose history the standalone ledger
- * never had.
- */
 export declare function mergeComputerActionSources(standalone: ComputerAction[], legacy: ComputerAction[]): ComputerAction[];
-/** Read `computer.action` events straight from the durable event ledger,
- *  newest first, bounded by `limit`. Malformed/legacy records (missing
- *  `command` or `pid`, or an unparseable `ts`) are skipped, never thrown —
- *  the ledger is a plain rotated JSONL file another process can be mid-write
- *  or mid-rotate against. */
 export declare function listComputerActions(opts?: {
     limit?: number;
 }): ComputerAction[];
-/** Why a row carries no session digest: `linked` resolved one, `unresolved`
- *  has a sessionId/launchId but no matching indexed session, `unlinked` has
- *  neither (a bare terminal invocation with no agent session env at all). */
 export type ComputerRunLinkStatus = 'linked' | 'unresolved' | 'unlinked';
-/** One task-first row: every `computer.action` emitted by one CLI process
- *  (see the module docblock's "Grouping key" note), plus the agent session
- *  it links to when resolvable. */
 export interface ComputerRunRow {
-    /** Invoking CLI process's pid. Absent on a run recovered from the DB after
-     *  the ledger pruned — that process is long gone and its pid unknowable. */
     pid?: number;
     invocationId?: string;
-    /**
-     * Total actions for a run recovered from the DB after the event ledger
-     * pruned its individual actions. Set ONLY on such rows: when it is present,
-     * `actions`/`counts` are empty because the per-verb detail is genuinely gone,
-     * and this total is all that survived. Live ledger rows leave it undefined
-     * and report real per-verb `counts` instead.
-     */
     recoveredActionCount?: number;
-    /** Truncated task description — present only for a `computer run --task`
-     *  invocation; a bare verb call has none. */
     task?: string;
-    /** Invoking machine's hostname — the CLI's own machine, not necessarily
-     *  the driven one (see `remoteHost`). */
     machine: string;
     machineId?: string;
-    /** `--device <device>` target when the run drove a remote (Windows) daemon. */
     remoteHost?: string;
-    /** Best-known target app bundle across the run's actions. */
     bundle?: string;
     agent?: string;
     sessionId?: string;
     launchId?: string;
     linkStatus: ComputerRunLinkStatus;
     linkedSession?: SessionMeta;
-    /** Newest first; excludes the `run` task marker itself. */
     actions: ComputerAction[];
-    /** Per-verb counts over `actions` (never includes the `run` marker). */
     counts: Record<string, number>;
-    /** Oldest action's mtime — the row's start. */
     startMs: number;
-    /** Newest action's mtime — the row's sort/age key. */
     endMs: number;
 }
-/**
- * Group flat ledger actions into task-first rows, newest first. Pure:
- * session resolvers are passed in, so this has no filesystem/session-index
- * dependency and is unit-testable with synthetic data (see
- * {@link buildComputerSessionRows} for the impure disk/index-reading caller).
- */
 export declare function groupIntoComputerRuns(actions: ComputerAction[], resolveSession?: (sessionId: string) => SessionMeta | null, resolveLaunch?: (launchId: string) => SessionMeta | null): ComputerRunRow[];
-/** Build task-first rows from the real ledger, resolving each row's owning
- *  session against the live indexes. The interactive picker's (and the
- *  flat/`--json` printer's) data source. `machine` narrows to rows whose
- *  invoking hostname, machineId, or `--device` target contains the substring. */
 export declare function buildComputerSessionRows(opts?: {
     limit?: number;
     machine?: string;
     observer?: string;
 }): ComputerRunRow[];
-/**
- * Search predicate for the interactive picker: task text, machine/remote
- * host, target bundle, the linked session's agent/topic/label, or any
- * driven verb in the row.
- */
 export declare function matchesComputerSessionRow(row: ComputerRunRow, queryText: string): boolean;
-/** Human one-line summary of a row's per-verb action counts, most frequent
- *  first — shared by the flat table and the interactive picker's label. */
-/**
- * One row's action summary — the single renderer every surface should use.
- *
- * A run recovered from the DB after the ledger pruned has no per-verb detail,
- * only a total. Rendering it through the per-verb formatter printed
- * "(no actions)", which is indistinguishable from a run that did nothing — so a
- * 40-action run read as empty. Report the surviving total, and say plainly that
- * the breakdown is gone rather than implying we still have it.
- */
 export declare function formatRowActions(row: ComputerRunRow): string;
 export declare function formatActionCounts(counts: Record<string, number>): string;
-/** Human table for the CLI. Returns lines (no trailing newline). */
 export declare function renderComputerSessionRows(rows: ComputerRunRow[]): string;
-/** Default row cap for the flat/non-interactive table. A computer row is
- *  much finer-grained than a browser task — real usage is mostly one
- *  standalone verb per CLI invocation, not a `run --task` loop, so an
- *  unbounded flat dump against real history reads as hundreds of one-action
- *  rows (confirmed against a real machine's history while building this).
- *  The interactive picker has no such cap (it's searchable); only the
- *  static table needs one. `--limit` overrides. */
 export declare const DEFAULT_ROW_DISPLAY_LIMIT = 50;
-/** Slice `rows` to at most `limit` (newest first, rows are already sorted),
- *  and report how many were dropped — pure, so the cap arithmetic and the
- *  trailer condition are unit-testable without a console spy. */
 export declare function applyRowDisplayLimit(rows: ComputerRunRow[], limit?: number): {
     shown: ComputerRunRow[];
     more: number;
 };
-/**
- * Shared CLI action for `agents computer sessions` and `agents sessions
- * --computer`. Non-interactive by design (the interactive routing decision
- * lives in `commands/computer-sessions-picker.ts`, mirroring
- * `runBrowserSessions`/`runBrowserSessionsCommand`'s split).
- */
 export declare function runComputerSessions(opts: {
     machine?: string;
     json?: boolean;
     limit?: number;
 }): void;
-/** Print already-collected rows. Fleet callers use this after merging local and
- * remote JSON so text, limits, and JSON keep exactly one renderer. */
 export declare function printComputerSessionRows(rows: ComputerRunRow[], opts: {
     json?: boolean;
     limit?: number;

package/dist/lib/computer/sessions-list.js

@@ -67,14 +67,8 @@ import { formatRelativeTime } from '../session/relative-time.js';
 import { getSessionById, listComputerSessionRecords, pruneToolSessions } from '../session/db.js';
 import { sessionHeadline } from '../session/title.js';
 import { buildLaunchSessionIndex, resolveLaunchSession, } from '../browser/sessions-list.js';
-/** Max chars of a `run --task` description persisted to the ledger — see the
- *  module docblock's retention/privacy note. */
 export const TASK_PREVIEW_MAX_CHARS = 200;
-/** Cap on how many raw ledger rows a single read scans/returns. `query()`
- *  already reads newest-first and stops at this cutoff mid-scan, so raising
- *  it only ever costs as much as the history actually holds. */
 const DEFAULT_ACTION_LIMIT = 5000;
-/** A capture record, accepted only when the producer gave a real path + name. */
 function parseActionCapture(value) {
     if (!value || typeof value !== 'object')
         return undefined;
@@ -113,32 +107,9 @@ function recordToAction(r) {
         capture: parseActionCapture(r.capture),
     };
 }
-/**
- * The standalone engine's OWN action ledger.
- *
- * `agents computer` is a thin consumer of the standalone `computer` engine
- * (PHNX-4075), and that engine ALWAYS appends every action it performs to
- * `<cache>/computer/actions/<day>.jsonl` — independently of whether agents-cli
- * was in the call at all. So a `computer` command the operator ran directly
- * appears ONLY here: it never reached `recordComputerAction`, so it is in
- * neither the feed event ledger nor `computer_sessions`. Reading only those two
- * meant the actions an operator actually performed were invisible to every
- * agents-cli surface.
- */
 export function standaloneComputerActionsDir() {
     return path.join(getCacheDir(), 'computer', 'actions');
 }
-/**
- * One line of the standalone ledger as a {@link ComputerAction}.
- *
- * The on-disk record is the same `computer.action` event the engine reports on
- * fd 4 — the contract `computer-client.ts` `ComputerActionEvent` already
- * describes and `recordComputerAction` already consumes — so this maps the same
- * fields rather than inventing a second vocabulary. A record missing the two
- * fields that make it an action at all (`command`, a parseable timestamp) is
- * skipped, never defaulted: the file is plain JSONL another process may be
- * mid-append to.
- */
 function standaloneLineToAction(line, observer) {
     let parsed;
     try {
@@ -159,19 +130,8 @@ function standaloneLineToAction(line, observer) {
         return null;
     const text = (key) => (typeof record[key] === 'string' ? record[key] : undefined);
     const num = (key) => (typeof record[key] === 'number' ? record[key] : undefined);
-    // The producer identifies the DRIVEN host only for a remote run, and emits no
-    // `hostname`/`machineId` of its own at all. Defaulting those to the observing
-    // machine HERE, at the source, is what keeps a direct local action attributable:
-    // without it `groupIntoComputerRuns` fell back to `machine: 'unknown'`, the row's
-    // device read `unknown`, and every locally-run `computer` action vanished the
-    // moment a consumer filtered by device. The observer IS the machine that ran it
-    // — this ledger is per-machine by construction, written by the engine on the box
-    // it ran on — so the fallback is a fact, not a guess. An explicit `host` still
-    // wins, because that names a genuinely different driven machine.
     return {
         verb, ts, tsMs,
-        // The engine's pid is its own; a record without one still groups by
-        // invocationId, which is the identity that actually matters here.
         pid: num('pid') ?? 0,
         invocationId: text('invocationId'),
         targetPid: num('targetPid'),
@@ -182,29 +142,21 @@ function standaloneLineToAction(line, observer) {
         launchId: text('launchId'),
         agent: text('agent'),
         machineId: text('machineId'),
+        // Attribute to the observer only when the engine omitted its source machine.
         hostname: text('hostname') ?? observer,
         capture: parseActionCapture(record.capture),
     };
 }
-/**
- * Read the standalone ledger, newest day first, bounded by `limit` actions.
- *
- * Bounded by construction: days are read newest-first and reading stops as soon
- * as the budget is met, so a box with months of history costs the same as one
- * with a day of it.
- */
 export function listStandaloneComputerActions(opts = {}) {
     const dir = opts.dir ?? standaloneComputerActionsDir();
     const limit = opts.limit ?? DEFAULT_ACTION_LIMIT;
-    // This ledger is per-machine by construction, so "who ran it" is this machine
-    // unless the record names a driven remote host.
     const observer = opts.observer ?? machineId();
     let days;
     try {
         days = fs.readdirSync(dir).filter((name) => name.endsWith('.jsonl')).sort().reverse();
     }
     catch {
-        return []; // The engine has never run here, or is not installed.
+        return [];
     }
     const out = [];
     for (const day of days) {
@@ -215,9 +167,8 @@ export function listStandaloneComputerActions(opts = {}) {
             lines = fs.readFileSync(path.join(dir, day), 'utf8').split('\n');
         }
         catch {
-            continue; /* rotated or removed mid-read */
+            continue;
         }
-        // Newest last within a day, and the budget favours the newest actions.
         for (let index = lines.length - 1; index >= 0 && out.length < limit; index--) {
             const line = lines[index];
             if (!line)
@@ -230,19 +181,6 @@ export function listStandaloneComputerActions(opts = {}) {
     out.sort((a, b) => b.tsMs - a.tsMs);
     return out;
 }
-/**
- * Union the two ledgers, preferring the standalone record for any run present in
- * both.
- *
- * Dedupe keys on `invocationId`, NOT on a timestamp or pid. When a command is
- * forwarded through `agents computer`, BOTH stores receive it — and the
- * forwarding rewrites `ts` and `pid` on the way through, so the two copies of one
- * action do not agree on either. `invocationId` is minted by the engine and
- * echoed unchanged, which makes it the only field that identifies the same run in
- * both files. A legacy feed record with no invocationId cannot be matched to
- * anything, so it is kept: dropping it would lose history the standalone ledger
- * never had.
- */
 export function mergeComputerActionSources(standalone, legacy) {
     const standaloneRuns = new Set();
     for (const action of standalone)
@@ -257,11 +195,6 @@ export function mergeComputerActionSources(standalone, legacy) {
     merged.sort((a, b) => b.tsMs - a.tsMs);
     return merged;
 }
-/** Read `computer.action` events straight from the durable event ledger,
- *  newest first, bounded by `limit`. Malformed/legacy records (missing
- *  `command` or `pid`, or an unparseable `ts`) are skipped, never thrown —
- *  the ledger is a plain rotated JSONL file another process can be mid-write
- *  or mid-rotate against. */
 export function listComputerActions(opts = {}) {
     const records = query({ eventTypes: ['computer.action'], limit: opts.limit ?? DEFAULT_ACTION_LIMIT });
     const out = [];
@@ -272,17 +205,9 @@ export function listComputerActions(opts = {}) {
     }
     return out;
 }
-/**
- * Group flat ledger actions into task-first rows, newest first. Pure:
- * session resolvers are passed in, so this has no filesystem/session-index
- * dependency and is unit-testable with synthetic data (see
- * {@link buildComputerSessionRows} for the impure disk/index-reading caller).
- */
 export function groupIntoComputerRuns(actions, resolveSession, resolveLaunch) {
     const byInvocation = new Map();
     for (const [index, a] of actions.entries()) {
-        // Legacy rows have no trustworthy process identity. Pids are recyclable,
-        // so preserve each event separately instead of inventing a relationship.
         const key = a.invocationId ?? `legacy:${a.pid}:${a.tsMs}:${index}`;
         const list = byInvocation.get(key) ?? [];
         list.push(a);
@@ -291,7 +216,7 @@ export function groupIntoComputerRuns(actions, resolveSession, resolveLaunch) {
     const rows = [];
     for (const group of byInvocation.values()) {
         const pid = group[0].pid;
-        group.sort((a, b) => b.tsMs - a.tsMs); // newest first
+        group.sort((a, b) => b.tsMs - a.tsMs);
         const marker = group.find((a) => a.verb === 'run');
         const driving = group.filter((a) => a.verb !== 'run');
         const counts = {};
@@ -330,54 +255,19 @@ export function groupIntoComputerRuns(actions, resolveSession, resolveLaunch) {
     rows.sort((a, b) => b.endMs - a.endMs);
     return rows;
 }
-/**
- * Add runs the event ledger no longer holds, from the durable
- * `computer_sessions` table (RUSH-2549).
- *
- * The ledger is deliberately bounded — it prunes at 7 days / 50 MiB — so before
- * this, a run simply disappeared from `agents sessions --computer` on day 8 even
- * though it had happened and its identity was known. The DB row is metadata
- * only, so a recovered row carries its identity, timing and action COUNT but no
- * per-verb breakdown: those individual actions lived in the pruned ledger and
- * are genuinely gone. It is listed as a real run with an empty `actions` list
- * rather than silently omitted, and never fabricated back.
- *
- * Ledger rows win on collision: while both exist the ledger is richer.
- */
 function appendPrunedRunsFromDb(rows, limit) {
     const seen = new Set(rows.map((r) => r.invocationId));
-    // Ask the DB for what the ledger CANNOT still hold — everything older than
-    // the oldest action the ledger returned. Reading the newest N instead is
-    // self-defeating: those are precisely the rows `seen` discards, so once the
-    // table exceeds the read limit the recovery returns nothing and history
-    // disappears past the ledger window again — the exact bug this recovery
-    // exists to prevent. With no ledger rows at all there is nothing to exclude,
-    // so every stored row is recoverable.
     const startedBeforeMs = rows.length > 0
         ? Math.min(...rows.map((r) => r.startMs))
         : undefined;
     for (const record of listComputerSessionRecords({ limit, startedBeforeMs })) {
-        // The dedup is LOAD-BEARING — do not delete it as redundant with the WHERE
-        // clause above. A run's DB `started_at` is its TRUE start and is never
-        // updated, while the ledger row's `startMs` is only its oldest RETAINED
-        // action. So a long `computer run` that began before the ledger window but
-        // kept acting inside it sits below the cutoff, is selected by the SQL, and
-        // is already present as a ledger row. This is what drops the duplicate.
         if (seen.has(record.invocationId))
             continue;
         const linked = record.sessionId ? getSessionById(record.sessionId) : null;
         rows.push({
-            // No pid: the process is long gone and the ledger entry that knew it has
-            // been pruned. Fabricating `0` rendered rows labelled "pid 0" (see the
-            // label fallbacks in this file and computer-sessions-picker.ts).
             pid: undefined,
             invocationId: record.invocationId,
             task: record.taskPreview,
-            // machineId() form ("zion"), the same normalized id the DB stored; the
-            // ledger path records the raw os.hostname() ("Zion.local") in `machine`.
-            // Setting BOTH from the one value we have keeps `--machine` substring
-            // filtering working on either spelling instead of silently missing
-            // recovered rows (events.ts documents the hostname/machineId split).
             machine: record.machine,
             machineId: record.machine,
             bundle: undefined,
@@ -387,10 +277,6 @@ function appendPrunedRunsFromDb(rows, limit) {
             launchId: record.launchId,
             linkStatus: linked ? 'linked' : (record.sessionId || record.launchId) ? 'unresolved' : 'unlinked',
             linkedSession: linked ?? undefined,
-            // The per-verb breakdown lived in the pruned ledger and is genuinely gone
-            // — it is never reconstructed. The TOTAL survives in the row, so report
-            // it as an explicit total rather than dropping it: a 40-action run must
-            // not render identically to one that did nothing.
             actions: [],
             counts: {},
             recoveredActionCount: record.actionCount,
@@ -399,24 +285,14 @@ function appendPrunedRunsFromDb(rows, limit) {
         });
     }
 }
-/** Build task-first rows from the real ledger, resolving each row's owning
- *  session against the live indexes. The interactive picker's (and the
- *  flat/`--json` printer's) data source. `machine` narrows to rows whose
- *  invoking hostname, machineId, or `--device` target contains the substring. */
 export function buildComputerSessionRows(opts = {}) {
-    const actions = mergeComputerActionSources(
-    // `observer` is threaded from the caller's scope so a row's device and the
-    // scope that reported it can never name the same box differently.
-    listStandaloneComputerActions({ limit: opts.limit, ...(opts.observer ? { observer: opts.observer } : {}) }), listComputerActions({ limit: opts.limit }));
+    const actions = mergeComputerActionSources(listStandaloneComputerActions({ limit: opts.limit, ...(opts.observer ? { observer: opts.observer } : {}) }), listComputerActions({ limit: opts.limit }));
     const index = buildLaunchSessionIndex();
     const rows = groupIntoComputerRuns(actions, (sessionId) => getSessionById(sessionId), (launchId) => resolveLaunchSession(index, launchId));
-    // Retention runs here, on the listing path, never on the action hot path:
-    // one row per `agents computer` CLI process means the table would otherwise
-    // grow without bound. Best-effort — a read-only DB must not break a listing.
     try {
         pruneToolSessions();
     }
-    catch { /* listing must not fail on retention */ }
+    catch { }
     appendPrunedRunsFromDb(rows, opts.limit);
     rows.sort((a, b) => b.endMs - a.endMs);
     if (!opts.machine)
@@ -426,11 +302,6 @@ export function buildComputerSessionRows(opts = {}) {
         r.remoteHost?.toLowerCase().includes(q) ||
         r.machineId?.toLowerCase().includes(q));
 }
-/**
- * Search predicate for the interactive picker: task text, machine/remote
- * host, target bundle, the linked session's agent/topic/label, or any
- * driven verb in the row.
- */
 export function matchesComputerSessionRow(row, queryText) {
     const q = queryText.trim().toLowerCase();
     if (!q)
@@ -449,17 +320,6 @@ export function matchesComputerSessionRow(row, queryText) {
     }
     return row.actions.some((a) => a.verb.toLowerCase().includes(q));
 }
-/** Human one-line summary of a row's per-verb action counts, most frequent
- *  first — shared by the flat table and the interactive picker's label. */
-/**
- * One row's action summary — the single renderer every surface should use.
- *
- * A run recovered from the DB after the ledger pruned has no per-verb detail,
- * only a total. Rendering it through the per-verb formatter printed
- * "(no actions)", which is indistinguishable from a run that did nothing — so a
- * 40-action run read as empty. Report the surviving total, and say plainly that
- * the breakdown is gone rather than implying we still have it.
- */
 export function formatRowActions(row) {
     if (row.recoveredActionCount !== undefined) {
         const n = row.recoveredActionCount;
@@ -473,7 +333,6 @@ export function formatActionCounts(counts) {
         .map(([verb, n]) => `${verb} ${n}`);
     return parts.join(', ') || '(no actions)';
 }
-/** Human table for the CLI. Returns lines (no trailing newline). */
 export function renderComputerSessionRows(rows) {
     if (rows.length === 0)
         return 'No computer actions recorded.';
@@ -492,33 +351,15 @@ export function renderComputerSessionRows(rows) {
     }
     return lines.join('\n');
 }
-/** Default row cap for the flat/non-interactive table. A computer row is
- *  much finer-grained than a browser task — real usage is mostly one
- *  standalone verb per CLI invocation, not a `run --task` loop, so an
- *  unbounded flat dump against real history reads as hundreds of one-action
- *  rows (confirmed against a real machine's history while building this).
- *  The interactive picker has no such cap (it's searchable); only the
- *  static table needs one. `--limit` overrides. */
 export const DEFAULT_ROW_DISPLAY_LIMIT = 50;
-/** Slice `rows` to at most `limit` (newest first, rows are already sorted),
- *  and report how many were dropped — pure, so the cap arithmetic and the
- *  trailer condition are unit-testable without a console spy. */
 export function applyRowDisplayLimit(rows, limit = DEFAULT_ROW_DISPLAY_LIMIT) {
     const shown = rows.slice(0, limit);
     return { shown, more: rows.length - shown.length };
 }
-/**
- * Shared CLI action for `agents computer sessions` and `agents sessions
- * --computer`. Non-interactive by design (the interactive routing decision
- * lives in `commands/computer-sessions-picker.ts`, mirroring
- * `runBrowserSessions`/`runBrowserSessionsCommand`'s split).
- */
 export function runComputerSessions(opts) {
     const rows = buildComputerSessionRows({ machine: opts.machine });
     printComputerSessionRows(rows, opts);
 }
-/** Print already-collected rows. Fleet callers use this after merging local and
- * remote JSON so text, limits, and JSON keep exactly one renderer. */
 export function printComputerSessionRows(rows, opts) {
     if (opts.json) {
         console.log(JSON.stringify(rows, null, 2));