@hwip/cli 0.0.1 → 0.1.0

package/dist/codex-config.d.ts

@@ -0,0 +1,24 @@
+/** The table hwip writes into a config that has none. No `env` block, unlike
+ *  the Cursor/Windsurf JSON entry: codex is a terminal app, so the server
+ *  inherits the shell's `HWIP_API_KEY`, and an unexpanded `"${HWIP_API_KEY}"`
+ *  literal would shadow the ~/.hwip/config.json fallback with junk (the same
+ *  reasoning as opencode's). */
+export declare const CODEX_MCP_TABLE: string;
+/**
+ * The config with hwip's entry present and current, leaving every other byte
+ * alone. Appended at the end when absent: a table header ends the table before
+ * it, so nothing above can capture the keys.
+ */
+export declare const upsertHwipMcpTable: (config: string) => string;
+/** The config with hwip's entry and its sub-tables gone, or null when it was
+ *  never there (so the caller can report "nothing to remove" rather than
+ *  rewriting an untouched file). */
+export declare const removeHwipMcpTable: (config: string) => string | null;
+/**
+ * The launch argv codex has recorded for hwip, verbatim, or null when there is
+ * no entry. Same contract as `registeredMcpArgv` in verify.ts: returned
+ * unnormalized, because a stale entry is only visible if the reader does not
+ * reshape it into what it expects.
+ */
+export declare const readHwipMcpArgv: (config: string) => string[] | null;
+//# sourceMappingURL=codex-config.d.ts.map

package/dist/codex-config.js

@@ -0,0 +1,169 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.readHwipMcpArgv = exports.removeHwipMcpTable = exports.upsertHwipMcpTable = exports.CODEX_MCP_TABLE = void 0;
+/**
+ * The hwip entry inside `~/.codex/config.toml`, which Codex CLI owns.
+ *
+ * Codex is the one supported agent whose MCP registry is TOML, and the file is
+ * the user's: it carries their model, their approval settings, their other
+ * servers. So this module works at the text level on the one table hwip owns
+ * (`[mcp_servers.hwip]`) and never rewrites the document — a parse-and-emit
+ * round trip through a TOML library would reorder their keys and drop their
+ * comments, which is a worse failure than the entry being missing.
+ *
+ * What that promise costs, stated once here because every function below is
+ * shaped by it:
+ *
+ *  - **Sub-tables are part of the entry.** Codex writes per-tool settings as
+ *    `[mcp_servers.hwip.tools.hwip_ask]` when the user picks "always allow".
+ *    Removal takes them along (a child of a deleted server is dead config);
+ *    re-install keeps them, since they are the user's answer, not ours.
+ *  - **Only `command` and `args` are ours.** Any other key in the table —
+ *    `cwd`, `startup_timeout_sec`, a comment — survives a re-install.
+ *  - **Comments before the next table belong to that table**, not to ours, so
+ *    the region we replace or delete stops short of them.
+ *
+ * Install, uninstall and verify all go through here so this is stated once.
+ */
+const mcp_command_js_1 = require("./mcp-command.js");
+const [MCP_BIN, ...MCP_SUBCOMMAND] = mcp_command_js_1.MCP_LAUNCH_ARGV;
+/** The table header, with or without the quotes TOML also allows. */
+const HWIP_TABLE_HEADER = /^\[mcp_servers\.(?:hwip|"hwip")\]$/;
+/** A sub-table of ours: `[mcp_servers.hwip.tools.hwip_ask]` and friends. */
+const HWIP_SUBTABLE_HEADER = /^\[mcp_servers\.(?:hwip|"hwip")\..+\]$/;
+/**
+ * The dotted/inline form — `mcp_servers.hwip = { command = "npx", … }` — which
+ * is valid TOML and which older hand-written configs use. It has to be found,
+ * because appending a header table beside it is a duplicate-key error that
+ * makes codex reject the WHOLE config, hwip's entry and the user's alike.
+ */
+const HWIP_INLINE_ENTRY = /^mcp_servers\.(?:hwip|"hwip")\s*=/;
+const ANY_TABLE_HEADER = /^\[/;
+const isHwipDefinition = (line) => HWIP_TABLE_HEADER.test(line.trim()) || HWIP_INLINE_ENTRY.test(line.trim());
+/** The keys hwip owns; everything else in the table is the user's. */
+const OWNED_KEY = /^(?:command|args)\s*=/;
+const commandLine = `command = "${MCP_BIN}"`;
+const argsLine = `args = [${MCP_SUBCOMMAND.map((a) => `"${a}"`).join(', ')}]`;
+/** The table hwip writes into a config that has none. No `env` block, unlike
+ *  the Cursor/Windsurf JSON entry: codex is a terminal app, so the server
+ *  inherits the shell's `HWIP_API_KEY`, and an unexpanded `"${HWIP_API_KEY}"`
+ *  literal would shadow the ~/.hwip/config.json fallback with junk (the same
+ *  reasoning as opencode's). */
+exports.CODEX_MCP_TABLE = ['[mcp_servers.hwip]', commandLine, argsLine].join('\n');
+/** CRLF in, CRLF out — a Windows config must not come back with mixed endings. */
+const eolOf = (config) => (config.includes('\r\n') ? '\r\n' : '\n');
+const splitLines = (config) => config.split(/\r?\n/);
+/** Line index of hwip's definition — header or inline — or -1. */
+const definitionIndex = (lines) => lines.findIndex((line) => isHwipDefinition(line));
+/** One past the last line of hwip's own key/value body (the next table header
+ *  of any kind, or EOF). Meaningless for the inline form, which is one line. */
+const bodyEnd = (lines, start) => {
+    const next = lines.slice(start + 1).findIndex((line) => ANY_TABLE_HEADER.test(line.trim()));
+    return next === -1 ? lines.length : start + 1 + next;
+};
+/** One past the last line of the whole entry: body plus every sub-table of
+ *  ours, stopping at the first header that belongs to someone else. */
+const entryEnd = (lines, start) => {
+    let end = bodyEnd(lines, start);
+    while (end < lines.length && HWIP_SUBTABLE_HEADER.test(lines[end].trim())) {
+        end = bodyEnd(lines, end);
+    }
+    return end;
+};
+/**
+ * `end` walked back past the blank lines and comments that precede whatever
+ * comes next. A comment sitting above `[mcp_servers.graft]` documents THAT
+ * server; deleting it with our table is the exact loss this module exists to
+ * avoid.
+ */
+const withoutTrailingPreamble = (lines, start, end) => {
+    let cut = end;
+    while (cut > start + 1) {
+        const line = lines[cut - 1].trim();
+        if (line === '' || line.startsWith('#'))
+            cut -= 1;
+        else
+            break;
+    }
+    return cut;
+};
+/** The document, ending in exactly one newline, so writing a config that
+ *  already carries the table is a no-op rather than a one-byte diff. */
+const rejoin = (lines, eol) => `${lines.join(eol).replace(/(?:\r?\n)+$/, '')}${eol}`;
+/**
+ * The config with hwip's entry present and current, leaving every other byte
+ * alone. Appended at the end when absent: a table header ends the table before
+ * it, so nothing above can capture the keys.
+ */
+const upsertHwipMcpTable = (config) => {
+    const eol = eolOf(config);
+    const lines = splitLines(config);
+    const start = definitionIndex(lines);
+    if (start === -1) {
+        const body = config.replace(/(?:\r?\n)+$/, '');
+        const table = exports.CODEX_MCP_TABLE.split('\n').join(eol);
+        return `${body ? `${body}${eol}${eol}` : ''}${table}${eol}`;
+    }
+    // The inline form is a single line and cannot hold keys of ours to keep.
+    if (HWIP_INLINE_ENTRY.test(lines[start].trim())) {
+        const table = exports.CODEX_MCP_TABLE.split('\n');
+        return rejoin([...lines.slice(0, start), ...table, ...lines.slice(start + 1)], eol);
+    }
+    const end = withoutTrailingPreamble(lines, start, bodyEnd(lines, start));
+    const kept = lines.slice(start + 1, end).filter((line) => !OWNED_KEY.test(line.trim()));
+    return rejoin([
+        ...lines.slice(0, start),
+        '[mcp_servers.hwip]',
+        commandLine,
+        argsLine,
+        ...kept,
+        ...lines.slice(end),
+    ], eol);
+};
+exports.upsertHwipMcpTable = upsertHwipMcpTable;
+/** The config with hwip's entry and its sub-tables gone, or null when it was
+ *  never there (so the caller can report "nothing to remove" rather than
+ *  rewriting an untouched file). */
+const removeHwipMcpTable = (config) => {
+    const eol = eolOf(config);
+    const lines = splitLines(config);
+    const start = definitionIndex(lines);
+    if (start === -1)
+        return null;
+    const end = HWIP_INLINE_ENTRY.test(lines[start].trim())
+        ? start + 1
+        : withoutTrailingPreamble(lines, start, entryEnd(lines, start));
+    const kept = [...lines.slice(0, start), ...lines.slice(end)];
+    // The removed entry left its blank separator behind; collapse the run so
+    // repeated install/uninstall cycles cannot grow the file.
+    return `${kept.join(eol).replace(/(?:\r?\n){3,}/g, `${eol}${eol}`).replace(/(?:\r?\n)+$/, '')}${eol}`;
+};
+exports.removeHwipMcpTable = removeHwipMcpTable;
+/**
+ * The launch argv codex has recorded for hwip, verbatim, or null when there is
+ * no entry. Same contract as `registeredMcpArgv` in verify.ts: returned
+ * unnormalized, because a stale entry is only visible if the reader does not
+ * reshape it into what it expects.
+ */
+const readHwipMcpArgv = (config) => {
+    const lines = splitLines(config);
+    const start = definitionIndex(lines);
+    if (start === -1)
+        return null;
+    // Joined, not scanned line by line: `args` is often written across several
+    // lines, and a line-wise reader drops it — which verify would then report
+    // as a stale registration for an entry that is in fact current.
+    const body = HWIP_INLINE_ENTRY.test(lines[start].trim())
+        ? lines[start]
+        : lines.slice(start + 1, bodyEnd(lines, start)).join('\n');
+    const command = body.match(/(?:^|[\s,{])command\s*=\s*["']([^"']+)["']/)?.[1];
+    if (!command)
+        return null;
+    const rawArgs = body.match(/(?:^|[\s,{])args\s*=\s*\[([^\]]*)\]/)?.[1] ?? '';
+    const args = rawArgs
+        .split(',')
+        .map((a) => a.trim().replace(/^["']|["']$/g, ''))
+        .filter(Boolean);
+    return [command, ...args];
+};
+exports.readHwipMcpArgv = readHwipMcpArgv;

package/dist/codex-transcript.d.ts

@@ -0,0 +1,59 @@
+/**
+ * Codex's rollout format, projected into the events the timeline draws.
+ *
+ * The third projector. Like pi's, everything here is Codex's vocabulary and
+ * belongs to Codex alone — `turn-watch` reaches it through `TranscriptProjector`
+ * and knows nothing about any of it.
+ *
+ * Shape measured 2026-09-14 against `~/.codex/sessions/2026/09/14/rollout-…jsonl`
+ * (77 lines, codex-cli 0.154.0, `gpt-5.6-luna`), cross-checked against the
+ * strings in the writer itself (`~/.codex/packages/standalone/current/bin/codex`)
+ * for the entry types that session happens not to contain.
+ *
+ * Every line is `{ timestamp, ordinal, type, payload }`. Two lanes describe the
+ * same turn, and this projector reads exactly one of them:
+ *
+ *  - `response_item` — what goes to the model: `message`, `reasoning`,
+ *    `custom_tool_call`, `function_call` and their `_output` twins.
+ *  - `event_msg` — what the UI is told: `item_completed` wrapping a typed
+ *    `item`, plus `token_count` and the task markers.
+ *
+ * `event_msg` wins, for three reasons measured in that session:
+ *
+ *  1. Its `UserMessage` items are the person's messages *only*. The
+ *     `response_item` lane files Codex's own injections under `role: 'user'`
+ *     too — the first user-role entry there is `# AGENTS.md instructions …`
+ *     followed by `<environment_context>` — and stamps no provenance on them.
+ *     Four user-role `response_item`s, three `UserMessage` items, and the one
+ *     left out is the injection. Codex has already made this call; pi's
+ *     projector had to guess at it with a wrapper regex because pi has no
+ *     equivalent lane.
+ *  2. `CommandExecution` carries `parsed_cmd`, Codex's own reading of what a
+ *     shell line does (`{ type: 'read', name: 'SKILL.md', path: '…' }`), plus
+ *     `exit_code`. The `response_item` twin carries a JavaScript program —
+ *     `const r = await tools.exec_command({cmd:"…"})` — whose command string
+ *     would have to be parsed back out of source text to label a row.
+ *  3. One lane cannot double-count. Reading both would put every tool call on
+ *     the timeline twice, and the two lanes share no id to merge on.
+ *
+ * The cost is latency, and it is real: an `item_completed` is written when the
+ * work finishes, so a two-minute build shows up two minutes in rather than at
+ * its start. The `response_item` lane is written at call time but cannot say
+ * whether the call succeeded — the honest row late beats the ambiguous row
+ * early, and a timeline that showed a call and never its outcome is the worse
+ * of the two failures.
+ *
+ * An item type this file does not name draws no row at all. Codex ships types no
+ * session on this machine has produced and will ship more; each needs a sample
+ * read before it can be projected, and until then a thinner timeline is the
+ * honest one. `FileChange` and `McpToolCall` were read from samples on
+ * 2026-10-02 (1 and 7 items) and are projected; `update` / `delete` changes and
+ * the failure forms rest on the writer's strings only, and say so where used.
+ */
+import { type TranscriptProjector } from './transcript-tail.js';
+/**
+ * Codex writes one line per completed item, so no event needs merging across
+ * lines — the same place this projector is simpler than Claude's.
+ */
+export declare const projectCodexEntries: TranscriptProjector;
+//# sourceMappingURL=codex-transcript.d.ts.map

package/dist/codex-transcript.js

@@ -0,0 +1,373 @@
+"use strict";
+/**
+ * Codex's rollout format, projected into the events the timeline draws.
+ *
+ * The third projector. Like pi's, everything here is Codex's vocabulary and
+ * belongs to Codex alone — `turn-watch` reaches it through `TranscriptProjector`
+ * and knows nothing about any of it.
+ *
+ * Shape measured 2026-09-14 against `~/.codex/sessions/2026/09/14/rollout-…jsonl`
+ * (77 lines, codex-cli 0.154.0, `gpt-5.6-luna`), cross-checked against the
+ * strings in the writer itself (`~/.codex/packages/standalone/current/bin/codex`)
+ * for the entry types that session happens not to contain.
+ *
+ * Every line is `{ timestamp, ordinal, type, payload }`. Two lanes describe the
+ * same turn, and this projector reads exactly one of them:
+ *
+ *  - `response_item` — what goes to the model: `message`, `reasoning`,
+ *    `custom_tool_call`, `function_call` and their `_output` twins.
+ *  - `event_msg` — what the UI is told: `item_completed` wrapping a typed
+ *    `item`, plus `token_count` and the task markers.
+ *
+ * `event_msg` wins, for three reasons measured in that session:
+ *
+ *  1. Its `UserMessage` items are the person's messages *only*. The
+ *     `response_item` lane files Codex's own injections under `role: 'user'`
+ *     too — the first user-role entry there is `# AGENTS.md instructions …`
+ *     followed by `<environment_context>` — and stamps no provenance on them.
+ *     Four user-role `response_item`s, three `UserMessage` items, and the one
+ *     left out is the injection. Codex has already made this call; pi's
+ *     projector had to guess at it with a wrapper regex because pi has no
+ *     equivalent lane.
+ *  2. `CommandExecution` carries `parsed_cmd`, Codex's own reading of what a
+ *     shell line does (`{ type: 'read', name: 'SKILL.md', path: '…' }`), plus
+ *     `exit_code`. The `response_item` twin carries a JavaScript program —
+ *     `const r = await tools.exec_command({cmd:"…"})` — whose command string
+ *     would have to be parsed back out of source text to label a row.
+ *  3. One lane cannot double-count. Reading both would put every tool call on
+ *     the timeline twice, and the two lanes share no id to merge on.
+ *
+ * The cost is latency, and it is real: an `item_completed` is written when the
+ * work finishes, so a two-minute build shows up two minutes in rather than at
+ * its start. The `response_item` lane is written at call time but cannot say
+ * whether the call succeeded — the honest row late beats the ambiguous row
+ * early, and a timeline that showed a call and never its outcome is the worse
+ * of the two failures.
+ *
+ * An item type this file does not name draws no row at all. Codex ships types no
+ * session on this machine has produced and will ship more; each needs a sample
+ * read before it can be projected, and until then a thinner timeline is the
+ * honest one. `FileChange` and `McpToolCall` were read from samples on
+ * 2026-10-02 (1 and 7 items) and are projected; `update` / `delete` changes and
+ * the failure forms rest on the writer's strings only, and say so where used.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.projectCodexEntries = void 0;
+const transcript_tail_js_1 = require("./transcript-tail.js");
+/** The item types this projector knows. Anything else draws no row — see the file header. */
+const CODEX_USER_MESSAGE = 'UserMessage';
+const CODEX_AGENT_MESSAGE = 'AgentMessage';
+const CODEX_REASONING = 'Reasoning';
+const CODEX_COMMAND = 'CommandExecution';
+const CODEX_EXTENSION = 'Extension';
+const CODEX_FILE_CHANGE = 'FileChange';
+const CODEX_MCP_CALL = 'McpToolCall';
+/**
+ * Which `parsed_cmd` field reads as "what this call is about", first match wins.
+ *
+ * Codex's own names, and a short list because `parsed_cmd` is already the
+ * vendor's summary rather than raw argv: a `read` entry carries `name` (the
+ * basename) and `path`, a search carries `query`. `cmd` — the reconstructed
+ * command line, and the field most likely to hold a token or a signed URL — is
+ * absent for the same reason `command` is absent from Claude's list.
+ */
+const CODEX_PARSED_KEYS = ['name', 'query', 'path'];
+/**
+ * Codex nests JSON inside JSON: an item's `content` arrives as a string holding
+ * an encoded array. Null on anything that is not JSON, which the callers read as
+ * "nothing to take from here".
+ */
+const safeParse = (raw) => {
+    try {
+        return JSON.parse(raw);
+    }
+    catch {
+        return null;
+    }
+};
+/** Prose out of a Codex content array. */
+const textOf = (content) => {
+    const items = typeof content === 'string' ? safeParse(content) : content;
+    if (!Array.isArray(items))
+        return '';
+    let text = '';
+    for (const block of items) {
+        if (!block || typeof block !== 'object')
+            continue;
+        const item = block;
+        // `UserMessage` blocks are typed `text`, `AgentMessage` blocks `Text` —
+        // measured, not assumed. The type IS checked, because the writer's
+        // content kinds include `SkillMention`, `Image` and `Audio`, and one of
+        // those carrying an incidental `text` field would otherwise be glued
+        // into the middle of what reads as the person's own sentence.
+        if (typeof item.type !== 'string' || item.type.toLowerCase() !== 'text')
+            continue;
+        if (typeof item.text === 'string')
+            text += item.text;
+    }
+    return text;
+};
+/**
+ * Whether a completed command actually succeeded.
+ *
+ * `exit_code` decides when there is one, and the absence of one is NOT success:
+ * an interrupted or aborted command completes as an item without ever having
+ * exited, and coercing that to 0 draws a green row for work that never
+ * finished. `status` is what Codex itself reports then — measured as
+ * `'completed'` on every item in the sampled session, alongside `failed` and
+ * `aborted` in the writer's own strings.
+ */
+const succeeded = (item) => typeof item.exit_code === 'number' ? item.exit_code === 0 : item.status === 'completed';
+const record = (value) => value && typeof value === 'object' ? value : null;
+/**
+ * `+` / `-` lines of a unified diff, file header (`+++` / `---` before the first
+ * `@@`) excluded — after it, a removed `-- sql comment` is a line like any other.
+ * `unified_diff` is the field name in the writer's own strings; no `update`
+ * entry exists in any rollout measured here, so this reads the standard format
+ * and nothing Codex-specific.
+ */
+const diffLineCounts = (diff) => {
+    let add = 0;
+    let del = 0;
+    let inHunk = false;
+    for (const line of diff.split('\n')) {
+        if (line.startsWith('@@'))
+            inHunk = true;
+        else if (!inHunk && (line.startsWith('+++') || line.startsWith('---')))
+            continue;
+        else if (line.startsWith('+'))
+            add++;
+        else if (line.startsWith('-'))
+            del++;
+    }
+    return { add, del };
+};
+/**
+ * What a `FileChange` row says about its patch: the first path, how many more
+ * there were, and numbers about the lines — never the lines. An `add` is
+ * measured (its `content` is the new file); an `update` reads its diff; a
+ * `delete` carries no count because no sample shows what it holds.
+ */
+const fileChangeSummary = (changes) => {
+    // A list is not the path-keyed object measured in the sample; its index
+    // keys would draw as file names.
+    const entries = Array.isArray(changes) ? [] : Object.entries(record(changes) ?? {});
+    if (entries.length === 0)
+        return {};
+    let add = 0;
+    let del = 0;
+    for (const [, change] of entries) {
+        const c = record(change);
+        if (!c)
+            continue;
+        if (c.type === 'add' && typeof c.content === 'string')
+            add += (0, transcript_tail_js_1.resultLinesOf)(c.content);
+        else if (c.type === 'update' && typeof c.unified_diff === 'string') {
+            const counts = diffLineCounts(c.unified_diff);
+            add += counts.add;
+            del += counts.del;
+        }
+    }
+    const rest = entries.length - 1;
+    const target = (0, transcript_tail_js_1.oneLine)(entries[0][0].trim());
+    // The suffix is added after the clamp so a long path cannot cut it off.
+    const suffix = rest > 0 ? ` (+${rest} more)` : '';
+    return {
+        ...(target ? { target: (0, transcript_tail_js_1.clamp)(target, transcript_tail_js_1.MAX_EVENT_FIELD_CHARS - suffix.length) + suffix } : {}),
+        ...(add ? { add } : {}),
+        ...(del ? { del } : {}),
+    };
+};
+/**
+ * The usage numbers on a `token_count` event.
+ *
+ * `last_token_usage` is this turn's, `total_token_usage` the session's running
+ * sum — the running one would make every row report the whole session.
+ *
+ * One event per usage tick, NOT one per assistant message: the sampled session
+ * holds 7 `token_count` events against 5 `AgentMessage` items across 3 turns.
+ * `mid` therefore means "one usage tick" here where it means "one API message"
+ * for Claude. The viewer only dedupes on it, so the finer grain costs nothing —
+ * but it is not a message id and nothing downstream may read it as one.
+ *
+ * Codex reports `input_tokens` as the full prompt with `cached_input_tokens`
+ * already inside it (measured: 16054 input of which 11904 cached, totalling 16067 with
+ * 13 output), so unlike Claude's three separate counters it is already the
+ * context number and must not be added to.
+ */
+const usageEvent = (payload, ordinal, index, model, at) => {
+    const info = record(payload.info);
+    const last = info && record(info.last_token_usage);
+    if (!last)
+        return null;
+    // Codex stamps no id on a usage event, so the line's own ordinal is the id:
+    // unique within a rollout and monotonic, which is all `mid` is for. A Codex
+    // release that renamed the field would otherwise drop every usage row,
+    // blanking the phone's token readout with no other symptom — so the line's
+    // timestamp and position stand in. The timestamp carries the weight: an
+    // index alone repeats across ticks (every tick has a `lines[0]`), and the
+    // viewer dedupes by `mid`, so two ticks' numbers would collapse into one.
+    const mid = typeof ordinal === 'number' ? String(ordinal) : `line-${at ?? 'unstamped'}-${index}`;
+    const reasoning = (0, transcript_tail_js_1.finiteNumber)(last.reasoning_output_tokens);
+    return {
+        kind: 'msg',
+        mid,
+        ...(model ? { model: (0, transcript_tail_js_1.clamp)(model) } : {}),
+        out: (0, transcript_tail_js_1.finiteNumber)(last.output_tokens),
+        ctx: (0, transcript_tail_js_1.finiteNumber)(last.input_tokens),
+        // Codex reports reasoning as tokens, not blocks. A non-zero count is
+        // still "it thought here", which is the only thing this field draws.
+        ...(reasoning ? { thinking: reasoning } : {}),
+        ...(at ? { at } : {}),
+    };
+};
+/**
+ * Codex writes one line per completed item, so no event needs merging across
+ * lines — the same place this projector is simpler than Claude's.
+ */
+const projectCodexEntries = (lines, opts = {}) => {
+    const events = [];
+    // The model is stamped on `turn_context`, once per turn, ahead of the usage
+    // events it applies to. Carried forward rather than looked up, because a
+    // tail that begins mid-session may never see one.
+    let model;
+    for (let index = 0; index < lines.length; index++) {
+        const entry = record(safeParse(lines[index]));
+        if (!entry)
+            continue;
+        const at = typeof entry.timestamp === 'string' ? entry.timestamp : undefined;
+        const stamp = at ? { at } : {};
+        if (entry.type === 'turn_context') {
+            const payload = record(entry.payload);
+            if (payload && typeof payload.model === 'string')
+                model = payload.model;
+            continue;
+        }
+        // `session_meta` is the cwd header the resolver reads, `world_state` and
+        // `token_usage_record` are bookkeeping, and `response_item` is the lane
+        // this projector deliberately does not read.
+        if (entry.type !== 'event_msg')
+            continue;
+        const payload = record(entry.payload);
+        if (!payload)
+            continue;
+        if (payload.type === 'token_count') {
+            const usage = usageEvent(payload, entry.ordinal, index, model, at);
+            if (usage)
+                events.push(usage);
+            continue;
+        }
+        if (payload.type !== 'item_completed')
+            continue;
+        const item = record(payload.item);
+        if (!item || typeof item.type !== 'string' || typeof item.id !== 'string') {
+            opts.onUnknown?.('codex item without a type or id');
+            continue;
+        }
+        if (item.type === CODEX_USER_MESSAGE) {
+            const text = textOf(item.content).trim();
+            if (text)
+                events.push({ kind: 'prompt', text: (0, transcript_tail_js_1.clamp)(text, transcript_tail_js_1.MAX_EVENT_TEXT_CHARS), ...stamp });
+            continue;
+        }
+        if (item.type === CODEX_AGENT_MESSAGE) {
+            const text = textOf(item.content).trim();
+            if (text)
+                events.push({ kind: 'text', text: (0, transcript_tail_js_1.clamp)(text, transcript_tail_js_1.MAX_EVENT_TEXT_CHARS), ...stamp });
+            continue;
+        }
+        // Reasoning is what the agent considered, not what it did — dropped
+        // here exactly as thinking blocks are for Claude and pi. Its size still
+        // reaches the timeline, as the `thinking` field on the usage event.
+        if (item.type === CODEX_REASONING)
+            continue;
+        if (item.type === CODEX_COMMAND) {
+            const parsed = Array.isArray(item.parsed_cmd) ? record(item.parsed_cmd[0]) : null;
+            // Codex's own reading of the command — `read`, `search`, `unknown`.
+            // The raw `command` argv is never consulted: it is `['/bin/zsh',
+            // '-lc', <the whole script>]`, which is the shape that carries
+            // secrets.
+            const name = parsed && typeof parsed.type === 'string' ? parsed.type : 'exec';
+            const target = (0, transcript_tail_js_1.oneLine)((0, transcript_tail_js_1.targetFrom)(parsed, CODEX_PARSED_KEYS));
+            const resultLines = (0, transcript_tail_js_1.resultLinesOf)(item.aggregated_output);
+            events.push({ kind: 'tool', id: item.id, name: (0, transcript_tail_js_1.clamp)(name), ...(target ? { target } : {}), ...stamp });
+            events.push({
+                kind: 'tool_result',
+                id: item.id,
+                ok: succeeded(item),
+                ...(resultLines ? { lines: resultLines } : {}),
+                ...stamp,
+            });
+            continue;
+        }
+        if (item.type === CODEX_EXTENSION) {
+            // `kind` is the extension that ran (`web.search`), `query` what it
+            // was asked. A search query is the user's own words, already on the
+            // wire as the prompt that produced it.
+            const name = typeof item.kind === 'string' ? item.kind : 'extension';
+            const target = (0, transcript_tail_js_1.oneLine)(typeof item.query === 'string' ? item.query : undefined);
+            events.push({ kind: 'tool', id: item.id, name: (0, transcript_tail_js_1.clamp)(name), ...(target ? { target: (0, transcript_tail_js_1.clamp)(target) } : {}), ...stamp });
+            events.push({
+                kind: 'tool_result',
+                id: item.id,
+                // No failure field has been observed on an `Extension` item, and
+                // an empty result list is a search that found nothing rather
+                // than one that broke. Left as success until a failing sample
+                // says what a failure looks like — a guessed field reads as a
+                // red row on every successful search instead.
+                ok: true,
+                ...(Array.isArray(item.results) ? { lines: item.results.length } : {}),
+                ...stamp,
+            });
+            continue;
+        }
+        if (item.type === CODEX_FILE_CHANGE) {
+            // `apply_patch` is Codex's own name for the tool that writes this.
+            // `status` decides, as it does for a command with no exit code:
+            // `declined` is a patch the person refused, and it wrote nothing.
+            events.push({ kind: 'tool', id: item.id, name: 'apply_patch', ...fileChangeSummary(item.changes), ...stamp });
+            const resultLines = (0, transcript_tail_js_1.resultLinesOf)(item.stdout);
+            events.push({
+                kind: 'tool_result',
+                id: item.id,
+                ok: item.status === 'completed',
+                ...(resultLines ? { lines: resultLines } : {}),
+                ...stamp,
+            });
+            continue;
+        }
+        if (item.type === CODEX_MCP_CALL) {
+            // `server.tool`, the same dotted shape as `web.search`. The
+            // `arguments` are the MCP server's schema, not Codex's, and can
+            // hold anything a tool takes — a body, a URL, a token — so no
+            // target is drawn from them and neither is the result's text.
+            const server = typeof item.server === 'string' ? item.server : '';
+            const tool = typeof item.tool === 'string' ? item.tool : '';
+            const name = server && tool ? `${server}.${tool}` : tool || server || 'mcp';
+            const result = record(item.result);
+            const resultLines = (0, transcript_tail_js_1.resultLinesOf)(result?.content);
+            events.push({ kind: 'tool', id: item.id, name: (0, transcript_tail_js_1.clamp)(name), ...stamp });
+            events.push({
+                kind: 'tool_result',
+                id: item.id,
+                // An `error` beside `completed` is still a failure: Codex files
+                // a call that reached the server and was refused as completed.
+                // The field's name is the writer's (`McpToolCallError`); no
+                // failing call is in any rollout measured here. `isError` is
+                // MCP's own tool-level failure flag inside the result.
+                ok: item.status === 'completed' && item.error == null && result?.isError !== true,
+                ...(resultLines ? { lines: resultLines } : {}),
+                ...stamp,
+            });
+            continue;
+        }
+        // An item type this file has never seen falls out here, and the
+        // timeline is thinner by one row rather than wrong by one. Naming it
+        // without reading its fields would strand a call that never resolves;
+        // reading its fields without a sample is guessing at a vendor's format.
+        // Saying that it happened is neither.
+        opts.onUnknown?.(`codex item ${item.type}`);
+    }
+    return (0, transcript_tail_js_1.sliceSinceLastPrompt)(events, opts);
+};
+exports.projectCodexEntries = projectCodexEntries;