@phnx-labs/agents-cli 1.22.103 → 1.22.105

package/dist/lib/agent-spec/agents.js

@@ -134,7 +134,7 @@ export function findInPath(command, options = {}) {
                 if (process.platform !== 'win32')
                     fs.accessSync(full, fs.constants.X_OK);
                 const native = resolveNativeBinaryPath(command, full, options);
-                if (native)
+                if (native && (!options.accept || options.accept(native)))
                     return native;
             }
             catch {

package/dist/lib/browser/drivers/ssh.js

@@ -11,7 +11,7 @@ export { shellQuote };
 // The `ssh -L` tunnel spawn is shared with `agents computer --device`; it lives in
 // the single ssh-tunnel helper. Calling it with no options preserves this
 // driver's original foreground, stderr-captured behavior exactly.
-import { startSSHTunnel } from '../../computer/ssh-tunnel.js';
+import { startSSHTunnel } from '../../ssh-tunnel.js';
 import { encodePwshBase64 } from '../../pwsh.js';
 /** Lifecycle for a registry-driven tunnel vs a profile the daemon launched. */
 export function persistRemoteLifecycle(persistRemote) {

package/dist/lib/computer/context.d.ts

@@ -0,0 +1,83 @@
+/**
+ * context.ts — everything agents-cli knows that the standalone `computer`
+ * engine cannot work out for itself, serialized as one JSON object onto fd 3.
+ *
+ * This is the whole contract of the consumer half, and it is deliberately four
+ * fields wide. The engine accepts exactly this shape:
+ *
+ *   version      `1`. The engine matches on it; a field added later must be
+ *                optional so an older engine keeps working.
+ *   permissions  which apps are allowed, derived from `Computer(<bundle-id>)`
+ *                rules in the agents permissions resource layer. The engine
+ *                would have to re-learn resource layering to compute this.
+ *   peers        which executables the daemon accepts a connection from.
+ *   target       the `--device <name>` target, resolved against the fleet:
+ *                devices registry, ssh identity, platform. The engine matches
+ *                its own `--device <alias>` against this instead of reading a
+ *                registry it does not have. Absent for a local invocation.
+ *   session      who is acting — actor id and agent session — so an action
+ *                lands in the right session history.
+ *
+ * WHAT IS DELIBERATELY NOT HERE. The transport (`COMPUTER_HELPER_TCP`,
+ * `COMPUTER_HELPER_VNC`, `COMPUTER_HELPER_SOCKET`), the remote helper's auth
+ * token, and the policy-file paths are the ENGINE's: it provisions the Windows
+ * helper, mints and stores the token, opens the `ssh -L` tunnel and hydrates its
+ * own transport from the state it wrote. agents-cli publishing a loopback
+ * endpoint here (or on `COMPUTER_HELPER_TCP`) would be a second, drifting copy
+ * of that answer — and a copy without the token, which the daemon rejects with
+ * `auth_failed`. Service-manager safety (launchd/systemd registration under a
+ * redirected HOME) is likewise the standalone's own: it inherits `HOME` and
+ * `AGENTS_REAL_HOME` and renders its own manifest, so agents-cli neither
+ * computes a label nor issues a verdict for it.
+ *
+ * The context is PUSHED (written and closed) rather than exposed as a callback,
+ * so the engine never re-enters agents-cli and there is exactly one direction of
+ * dependency.
+ */
+/** A `--device <name>` target, resolved against the fleet. */
+export interface ComputerTargetContext {
+    /** The device name as the user typed it. */
+    alias: string;
+    /** `user@host`, already validated against ssh option injection. */
+    host: string;
+    user: string;
+    /** Bare host — the ssh-config Host name or address, without the user. */
+    hostname: string;
+    platform: string;
+    /** Per-device ssh identity flags, in argv order. Possibly empty. */
+    sshArgs: string[];
+}
+/** Who is acting, so the engine can stamp the action it reports back. */
+export interface ComputerSessionContext {
+    sessionId?: string;
+    launchId?: string;
+    actor: string;
+}
+export interface ComputerContext {
+    version: 1;
+    permissions?: {
+        allow: string[];
+    };
+    peers: {
+        allow: string[];
+    };
+    target?: ComputerTargetContext;
+    session: ComputerSessionContext;
+}
+export interface BuildContextOptions {
+    /** `--device <name>`, if given. */
+    device?: string;
+    /** Direct host targeting, which bypasses fleet resolution. */
+    host?: string;
+    /** Resolved path of the standalone executable, for the peer allow list. */
+    computerBin?: string;
+}
+/**
+ * Build the context handed to the engine on fd 3.
+ *
+ * `device` resolution goes through the shared fleet resolver and keeps the
+ * Windows expectation the computer subsystem has always enforced — a
+ * `--device` pointing at a Mac gets the same refusal as before, from the fleet
+ * layer that can actually see the device's platform.
+ */
+export declare function buildComputerContext(opts?: BuildContextOptions): Promise<ComputerContext>;

package/dist/lib/computer/context.js

@@ -0,0 +1,91 @@
+/**
+ * context.ts — everything agents-cli knows that the standalone `computer`
+ * engine cannot work out for itself, serialized as one JSON object onto fd 3.
+ *
+ * This is the whole contract of the consumer half, and it is deliberately four
+ * fields wide. The engine accepts exactly this shape:
+ *
+ *   version      `1`. The engine matches on it; a field added later must be
+ *                optional so an older engine keeps working.
+ *   permissions  which apps are allowed, derived from `Computer(<bundle-id>)`
+ *                rules in the agents permissions resource layer. The engine
+ *                would have to re-learn resource layering to compute this.
+ *   peers        which executables the daemon accepts a connection from.
+ *   target       the `--device <name>` target, resolved against the fleet:
+ *                devices registry, ssh identity, platform. The engine matches
+ *                its own `--device <alias>` against this instead of reading a
+ *                registry it does not have. Absent for a local invocation.
+ *   session      who is acting — actor id and agent session — so an action
+ *                lands in the right session history.
+ *
+ * WHAT IS DELIBERATELY NOT HERE. The transport (`COMPUTER_HELPER_TCP`,
+ * `COMPUTER_HELPER_VNC`, `COMPUTER_HELPER_SOCKET`), the remote helper's auth
+ * token, and the policy-file paths are the ENGINE's: it provisions the Windows
+ * helper, mints and stores the token, opens the `ssh -L` tunnel and hydrates its
+ * own transport from the state it wrote. agents-cli publishing a loopback
+ * endpoint here (or on `COMPUTER_HELPER_TCP`) would be a second, drifting copy
+ * of that answer — and a copy without the token, which the daemon rejects with
+ * `auth_failed`. Service-manager safety (launchd/systemd registration under a
+ * redirected HOME) is likewise the standalone's own: it inherits `HOME` and
+ * `AGENTS_REAL_HOME` and renders its own manifest, so agents-cli neither
+ * computes a label nor issues a verdict for it.
+ *
+ * The context is PUSHED (written and closed) rather than exposed as a callback,
+ * so the engine never re-enters agents-cli and there is exactly one direction of
+ * dependency.
+ */
+import { resolveActor } from '../actor.js';
+import { loadComputerAllowList, loadDefaultPeers } from './policy.js';
+import { resolveRemoteDevice } from '../ssh-tunnel.js';
+/**
+ * Which agent session is acting. Same precedence the admission cache used
+ * before the extraction — the harness-native id first, then agents' own.
+ */
+function agentSessionId(env = process.env) {
+    return env.CODEX_THREAD_ID
+        || env.CLAUDE_CODE_SESSION_ID
+        || env.CLAUDE_SESSION_ID
+        || env.AGENTS_SESSION_ID
+        || env.AGENT_SESSION_ID
+        || env.AGENTS_RUN_ID
+        || undefined;
+}
+/**
+ * Build the context handed to the engine on fd 3.
+ *
+ * `device` resolution goes through the shared fleet resolver and keeps the
+ * Windows expectation the computer subsystem has always enforced — a
+ * `--device` pointing at a Mac gets the same refusal as before, from the fleet
+ * layer that can actually see the device's platform.
+ */
+export async function buildComputerContext(opts = {}) {
+    let target;
+    if (opts.device) {
+        const resolved = await resolveRemoteDevice(opts.device, {
+            expectPlatform: 'windows',
+            forWhat: '`agents computer --device` drives the Windows computer-helper daemon, so it',
+        });
+        target = {
+            alias: opts.device,
+            host: resolved.target,
+            user: resolved.user,
+            hostname: resolved.host,
+            platform: resolved.device.platform,
+            sshArgs: resolved.identityArgs,
+        };
+    }
+    return {
+        version: 1,
+        ...(!opts.device && !opts.host && !process.env.COMPUTER_HELPER_TCP && !process.env.COMPUTER_HELPER_VNC
+            ? { permissions: { allow: loadComputerAllowList() } } : {}),
+        peers: { allow: loadDefaultPeers({ computerBin: opts.computerBin }) },
+        // Spread rather than assigned: a local invocation must not ship a `target`
+        // key at all, so the engine never has to distinguish absent from null.
+        ...(target ? { target } : {}),
+        session: {
+            sessionId: agentSessionId(),
+            launchId: process.env.AGENT_LAUNCH_ID,
+            actor: resolveActor().id,
+        },
+    };
+}

package/dist/lib/computer/policy.d.ts

@@ -0,0 +1,46 @@
+/** Resolve Agents permission groups and caller identities for the standalone
+ * engine. The engine alone writes helper policy and peer files. */
+export declare function loadComputerAllowList(): string[];
+/**
+ * Default peer set: the standalone `computer` executable, this `agents` CLI's
+ * own runtime, plus Rush.app if it's installed. realpath() the symlink chain so
+ * we record the on-disk path the helper will see via proc_pidpath, not the shim
+ * path.
+ *
+ * The standalone's path is the one that changed with PHNX-4075: the daemon's
+ * caller is now the engine process, not this CLI. `agents`' own execPath stays
+ * on the list because the engine may be a `.js` bin run through this same
+ * runtime (`invocation()` in computer-client.ts), in which case proc_pidpath
+ * still reports the runtime.
+ *
+ * Why path-based instead of codesign-team-id? The agents CLI is unsigned
+ * today (npm distribution), and even if we sign Rush.app the team-id
+ * check would need a separate roundtrip. Path is concrete and fast; the
+ * daemon already runs as the user so anyone who can swap a binary at
+ * these paths can do worse via other means.
+ */
+export declare function loadDefaultPeers(opts?: {
+    computerBin?: string;
+}): string[];
+/**
+ * Parse a `host:port` VNC endpoint, defaulting the port to 5901. Pure.
+ *
+ * Kept on the consumer side because the `--vnc` FLAG is parsed here — the
+ * platform gate has to know whether a remote desktop was named before the
+ * engine is ever spawned (see `shouldBlockOffPlatform`). The RFB protocol
+ * implementation itself went to the engine.
+ */
+export declare function parseVncEndpoint(raw: string | undefined): {
+    host: string;
+    port: number;
+} | null;
+export declare function resolveTcpEndpoint(): {
+    host: string;
+    port: number;
+    token: string | null;
+} | null;
+export declare function resolveVncEndpoint(): {
+    host: string;
+    port: number;
+    password: string;
+} | null;

package/dist/lib/computer/policy.js

@@ -0,0 +1,160 @@
+/** Resolve Agents permission groups and caller identities for the standalone
+ * engine. The engine alone writes helper policy and peer files. */
+import * as fs from 'fs';
+import * as path from 'path';
+import { getUserPermissionsDir, getPermissionsDir } from '../state.js';
+// Walk all permission group YAMLs (user dir wins on name collision) and
+// collect Computer(<bundle-id>) patterns from each group's `allow:` list.
+// Returns distinct bundle ids. Line-by-line regex extraction matches
+// buildPermissionsFromGroups: YAML parsers stumble on the nested quotes in
+// some rule values, but the strict pattern below catches our shape cleanly.
+export function loadComputerAllowList() {
+    const seenFiles = new Set();
+    const allowed = new Set();
+    for (const baseDir of [getUserPermissionsDir(), getPermissionsDir()]) {
+        const groupsDir = path.join(baseDir, 'groups');
+        if (!fs.existsSync(groupsDir))
+            continue;
+        let entries;
+        try {
+            entries = fs.readdirSync(groupsDir, { withFileTypes: true });
+        }
+        catch {
+            continue;
+        }
+        for (const entry of entries) {
+            if (!entry.isFile())
+                continue;
+            if (!entry.name.endsWith('.yml') && !entry.name.endsWith('.yaml'))
+                continue;
+            // User dir wins on filename collision.
+            const stem = entry.name.replace(/\.(yaml|yml)$/, '');
+            if (seenFiles.has(stem))
+                continue;
+            seenFiles.add(stem);
+            const filePath = path.join(groupsDir, entry.name);
+            let content;
+            try {
+                content = fs.readFileSync(filePath, 'utf-8');
+            }
+            catch {
+                continue;
+            }
+            // Strict regex: optional whitespace, dash, quoted Computer(<id>).
+            // Only honors `allow:` lines — `deny:` Computer patterns would be a
+            // contradiction (everything is deny-by-default already).
+            let inAllow = false;
+            for (const rawLine of content.split('\n')) {
+                const line = rawLine.replace(/\r$/, '');
+                const sectionMatch = line.match(/^(\w+)\s*:\s*$/);
+                if (sectionMatch) {
+                    inAllow = sectionMatch[1] === 'allow';
+                    continue;
+                }
+                if (!inAllow)
+                    continue;
+                const ruleMatch = line.match(/^\s*-\s*"Computer\(([^)]+)\)"\s*$/);
+                if (ruleMatch) {
+                    const bundleId = ruleMatch[1].trim();
+                    if (bundleId.length > 0)
+                        allowed.add(bundleId);
+                }
+            }
+        }
+    }
+    return [...allowed].sort();
+}
+/**
+ * Default peer set: the standalone `computer` executable, this `agents` CLI's
+ * own runtime, plus Rush.app if it's installed. realpath() the symlink chain so
+ * we record the on-disk path the helper will see via proc_pidpath, not the shim
+ * path.
+ *
+ * The standalone's path is the one that changed with PHNX-4075: the daemon's
+ * caller is now the engine process, not this CLI. `agents`' own execPath stays
+ * on the list because the engine may be a `.js` bin run through this same
+ * runtime (`invocation()` in computer-client.ts), in which case proc_pidpath
+ * still reports the runtime.
+ *
+ * Why path-based instead of codesign-team-id? The agents CLI is unsigned
+ * today (npm distribution), and even if we sign Rush.app the team-id
+ * check would need a separate roundtrip. Path is concrete and fast; the
+ * daemon already runs as the user so anyone who can swap a binary at
+ * these paths can do worse via other means.
+ */
+export function loadDefaultPeers(opts = {}) {
+    const out = new Set();
+    const add = (p) => {
+        try {
+            out.add(fs.realpathSync(p));
+        }
+        catch {
+            out.add(p);
+        }
+    };
+    // The standalone engine — the process that actually opens the socket now.
+    if (opts.computerBin)
+        add(opts.computerBin);
+    // The runtime currently running this CLI. Still a possible proc_pidpath when
+    // the engine is a .js bin executed through it.
+    if (process.execPath)
+        add(process.execPath);
+    // Rush.app — the consumer Electron client. Both the helper-binary and
+    // the main app binary are possible callers depending on how Rush wires
+    // the RPC client.
+    const rushCandidates = [
+        '/Applications/Rush.app/Contents/MacOS/Rush',
+        '/Applications/Rush.app/Contents/MacOS/Electron',
+    ];
+    for (const p of rushCandidates) {
+        if (fs.existsSync(p))
+            add(p);
+    }
+    return [...out].sort();
+}
+/**
+ * Parse a `host:port` VNC endpoint, defaulting the port to 5901. Pure.
+ *
+ * Kept on the consumer side because the `--vnc` FLAG is parsed here — the
+ * platform gate has to know whether a remote desktop was named before the
+ * engine is ever spawned (see `shouldBlockOffPlatform`). The RFB protocol
+ * implementation itself went to the engine.
+ */
+export function parseVncEndpoint(raw) {
+    if (!raw || raw.length === 0)
+        return null;
+    const idx = raw.lastIndexOf(':');
+    const host = idx >= 0 ? raw.slice(0, idx) : raw;
+    const portStr = idx >= 0 ? raw.slice(idx + 1) : '5901';
+    const port = Number(portStr);
+    if (!Number.isInteger(port) || port <= 0 || port > 65535)
+        return null;
+    return { host: host || '127.0.0.1', port };
+}
+// Resolve the TCP endpoint for a remote daemon (the Windows helper), if
+// configured. That helper binds loopback TCP and is reached over an `ssh -L`
+// tunnel, so the endpoint is a local forwarded port. COMPUTER_HELPER_TCP is
+// "host:port" (host defaults to 127.0.0.1); COMPUTER_HELPER_TOKEN is the shared
+// secret sent in the first `auth` frame.
+export function resolveTcpEndpoint() {
+    const raw = process.env.COMPUTER_HELPER_TCP;
+    if (!raw || raw.length === 0)
+        return null;
+    const [hostPart, portPart] = raw.includes(':') ? raw.split(':') : ['127.0.0.1', raw];
+    const port = Number(portPart);
+    if (!Number.isInteger(port) || port <= 0)
+        return null;
+    const token = process.env.COMPUTER_HELPER_TOKEN;
+    return { host: hostPart || '127.0.0.1', port, token: token && token.length > 0 ? token : null };
+}
+// Resolve the VNC/RFB endpoint for driving a remote GUI desktop over the RFB
+// protocol (an x11vnc/Xvnc server — e.g. a headless Linux desktop or an LXD
+// container exposing x11vnc on the host's Tailscale IP). COMPUTER_HELPER_VNC is
+// "host:port" (port defaults to 5901); COMPUTER_HELPER_VNC_PASSWORD is the VNC
+// password.
+export function resolveVncEndpoint() {
+    const parsed = parseVncEndpoint(process.env.COMPUTER_HELPER_VNC);
+    if (!parsed)
+        return null;
+    return { ...parsed, password: process.env.COMPUTER_HELPER_VNC_PASSWORD ?? '' };
+}

package/dist/lib/computer/record.d.ts

@@ -0,0 +1,38 @@
+/**
+ * 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 type { ComputerActionEvent } from '../computer-client.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 declare const COMPUTER_INVOCATION_ID: `${string}-${string}-${string}-${string}-${string}`;
+/**
+ * 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 declare function recordComputerAction(event: ComputerActionEvent, opts?: {
+    device?: string;
+}): void;

package/dist/lib/computer/record.js

@@ -0,0 +1,86 @@
+/**
+ * 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 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;
+    try {
+        emitEvent('computer.action', {
+            command,
+            invocationId: runId,
+            ...(drivenHost ? { host: drivenHost } : {}),
+            ...(sessionId ? { sessionId } : {}),
+            ...(launchId ? { launchId } : {}),
+            ...extra,
+        });
+    }
+    catch {
+        // Feed emission is best-effort; the action is already done.
+    }
+    try {
+        recordComputerSession({
+            invocationId: runId,
+            sessionId: sessionId ?? process.env.AGENT_SESSION_ID ?? process.env.AGENTS_SESSION_ID,
+            launchId: launchId ?? process.env.AGENT_LAUNCH_ID,
+            actor: actor ?? resolveActor().id,
+            actionCount: 1,
+            taskPreview: typeof extra.task === 'string' ? extra.task : undefined,
+        });
+    }
+    catch {
+        // Recording is best-effort; the action and its event are already done.
+    }
+}

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

@@ -2,9 +2,9 @@
  * Read-only task/run history over the `computer.action` event ledger
  * (`~/.agents/.history/events/YYYY-MM-DD/events.jsonl`, see `../events.ts`) —
  * the durable, already-existing audit log every `agents computer <verb>`
- * invocation (the explicit CLI verbs in `commands/computer-actions.ts`, and
- * the embedded `computer run` loop in `computer/dispatch.ts`) writes through
- * `emitComputerAction()`. Backs both `agents computer sessions` and the
+ * invocation writes through `computer/record.ts`'s `recordComputerAction()`,
+ * fed by the action events the standalone engine streams back (PHNX-4075).
+ * Backs both `agents computer sessions` and the
  * `agents sessions --computer` alias.
  *
  * There is no separate capture directory the way browser tasks have
@@ -24,7 +24,7 @@
  * the ledger's 7 days, and one row per CLI process would otherwise grow without
  * limit. It is metadata only. Nothing sensitive is persisted: `type` /
  * `type-text` events already carry only `textLength`, never the typed text
- * (see `commands/computer-actions.ts` `emitComputerAction` call sites) — the
+ * (see `computer/record.ts` `recordComputerAction`) — the
  * mission this module fulfils changes NONE of that. A `run --task`
  * description is the agent's OWN instruction, not typed-into-a-target-app
  * content (the same class of thing `agents sessions` already stores
@@ -35,10 +35,10 @@
  * deliberate exception to (not a bypass of) the automatic prompt-redaction
  * path in `events.ts` `sanitizePayload`.
  *
- * Grouping key: `emitComputerAction()` stamps one random `invocationId` for
+ * Grouping key: `recordComputerAction()` stamps one random `invocationId` for
  * the lifetime of the emitting CLI process. The event's own `pid` field is the emitting
  * CLI PROCESS's pid, never the target app's (that's `targetPid` — see
- * `computer-actions.ts` `emitComputerAction`, and its `#11` test guarding
+ * `computer/record.ts` `recordComputerAction`, and its `#11` test guarding
  * this). One `agents computer <verb>` invocation is one process, and
  * `computer run`'s whole embedded observe/act/verify loop is ALSO one
  * process. Grouping by `invocationId` gives exactly one row per CLI invocation without