@platless/axom-cli 0.1.0 → 0.3.13

package/dist/workstation/acp/registry/catalog.js

@@ -1,18 +1,208 @@
+/**
+ * Axom 认证过的 agent 清单 —— 取代 `officialCli.ts`。
+ *
+ * ## 它是什么：Axom 对官方 registry 的本地扩展层
+ *
+ * 一个 agent 在本清单里，就是我们真机验证过（roster 的 `curated`），设置页把它放进展开区；其余官方
+ * 条目进折叠的 "Unverified Agents"。本清单能做的事，各有一节在下面：
+ *
+ * - **推荐**：`recommended` 是静态的，只给愿意向任何一台新机器推荐的（claude、codex、pi）。
+ * - **本地检测**（`detect`，见 `detect.ts`）：PATH 上的命令或固定文件位置，只看文件在不在、不起进程。
+ *   检测到 = 这台机器的用户自己在用它，于是它也进推荐位，原因写"本机在用"。
+ * - **前置依赖**（`prerequisite`）：适配器之外、它起得来所必需的本体（Pi 的 CLI、ZCode 桌面应用），
+ *   同样靠 `detect` 判断在不在；有 `install` 就由 Install 先装，没有就只告诉用户怎么办。
+ * - **补充、取代与钉版本**：`supplement` / `supersedes` / `distribution`，以及 `launchEnv`。
+ *
+ * ## 托管与检测是两件事
+ *
+ * Axom 启动的**一律是 Axom 托管的那份**——npx 缓存、`uv tool dir`、`<config dir>/acp-adapters` 里我们
+ * 自己装的、钉了版本的副本，与用户自己的安装隔离、独立升级。`adapterInstalled` 只回答这一份在不在。
+ * 用户 PATH 上的 `kimi`、`command-code` **不算** Axom 已安装，也从不被拿来启动：它只是 `detect` 的
+ * 推荐信号。两份共用数据目录（`~/.kimi-code`、`~/.commandcode`），所以登录是共享的。
+ *
+ * ## 它与被它取代的那张表不是一回事
+ *
+ * `officialCli.ts` 断言的是"这个 agent 的官方 CLI 在不在 PATH"，而那个信号既不决定能否启动
+ * （npx 适配器多数自带引擎），也不决定能否使用（凭据才是），于是它撑起来的 `Installed` 徽章
+ * 是一句没人能负责的话。本清单不做任何这类断言：它只提供**我们自己认证过**的三样东西 ——
+ * 用户友好的默认名字、这个 agent 除适配器之外还需要什么、以及它是否进推荐位；本地检测也只回答
+ * "用户自己装了没有"，从不替 Axom 托管的那份作答。
+ *
+ * ## 为什么不为全部 39 个 agent 建表
+ *
+ * 见 spec §2.3：适配器需不需要本机 vendor CLI 是**版本级**属性，只能靠扒依赖树猜，而且完全
+ * 没有必要 —— 试跑失败时 agent 自己那句话（`Pi needs to be installed. Install it via …`）
+ * 带着确切的安装命令，且永远与它自身版本同步。本清单只覆盖我们真机验证过的少数几个。
+ *
+ * ## `prerequisite.install` 是安全边界
+ *
+ * 它会在工作站上**直接执行**，不弹二次确认。所以它只能是本文件里的字面量参数数组，永远不接受
+ * 来自 registry、agent 响应、网络内容或用户输入的字符串；以 argv 形式交给 execFile，不经 shell。
+ * `catalog.test.ts` 有一条机械守卫盯着这件事。
+ *
+ * ## `distribution` 覆盖 registry 的安装来源
+ *
+ * 这里写下的来源**整个替换** registry 的 `version` 与 `distribution`，id 与展示名仍是 registry 的，
+ * 于是已有的配置条目、roster、安装、启动、更新都不用知道发生过替换（见 {@link withCatalogOverrides}）。
+ * 本文件里的是长期的（Qoder：registry 落后于验证过的原生版本）；临时的钉版本放在
+ * axom-patch/cli/runtime.json，按 registry 版本挑选（`when_registry_version` / `until_registry_version`，
+ * 见 `patchAssets.ts`），registry 一到就自己让位。两者与上面的 `install` 是同一条安全边界：只能是
+ * 随 CLI 发布、钉死版本、由真机验证过的可信配置。
+ *
+ * ## `supplement` 与 `supersedes`：registry 缺的条目、registry 不肯撤的条目
+ *
+ * registry 的 `kimi` 跟的是 `MoonshotAI/kimi-cli`，那个仓库已归档，停在 1.52.0；继任者 Kimi Code
+ * （`MoonshotAI/kimi-code`）的条目 `kimi-code` 还在 registry#458 里等审核。Command Code 与社区的
+ * ZCode 适配器（registry#566、#650）也都还没进 registry。registry 没有「已停止维护」这样的字段
+ * （agent.schema.json 只有 `preview` 渠道），所以由本清单声明：
+ *
+ * - `supplement`：registry 里**没有**这个 id 时由我们补上的整条条目，钉死版本。registry 一收录这个 id
+ *   就用 registry 的，之后的版本由 registry 的机器人每小时跟进，补充条目不再生效。
+ * - `supersedes`：被这个条目取代的 registry id，从列表里隐藏。Kimi Code 装上后会把旧版的数据目录
+ *   迁走，旧适配器从此看不见用户的登录（2026-09-25 实测），两个并列只会让人选错。
+ *
+ * ## `launchEnv`：Axom 启动适配器时带的环境变量
+ *
+ * 经 ACP 适配器拉起的 agent 跑在无头/SDK 模式，它们的默认工具集与用户在终端里交互使用时**不同**，
+ * 而差出来的恰好是我们要的东西。2026-09-30 实测：claude-agent-acp 0.84.0 拉起的 Claude Code 没有
+ * TaskCreate/TaskUpdate/TodoWrite（ToolSearch 答 "No matching deferred tools found"），codex-acp
+ * 2.0.1 拉起的 Codex 0.159.2 没有 `update_plan`（问它自己答 "NO"）——于是这两个 agent 从不发 ACP
+ * `plan`，生产上三天 218 个外部会话一张计划卡都没有。各自打开一个开关后同一段提示词分别发出 14 次与
+ * 4 次 `plan`。
+ *
+ * 这里写下的变量并进 registry 条目的 `distribution.*.env`，所以它是**最底下的一层**：registry
+ * 自己声明的 env、工作站配置、用户按 agent 配的 `agentEnv` 都能覆盖它（见 `connectAgent`）。一个
+ * 用户自己配了 `CODEX_CONFIG` 的 Codex 因此会整份替换掉这里的值——那是显式配置，按它来；要保留计划
+ * 工具，把 `tools.update_plan.enabled` 写进自己那份里。
+ *
+ * 这些开关不是上游文档化的稳定接口，适配器升级时要复核仍然生效（上面那段实测的做法：直接用 ACP
+ * 客户端拉起适配器，问它有没有计划工具）。
+ */
+import { patchOverridesFor } from '../patchAssets.js';
+// Temporary distribution/environment overrides are bundled from axom-patch/cli/runtime.json.
 export const AXOM_AGENT_CATALOG = [
-    { registryAgent: 'claude-acp', defaultName: 'claude-agent', defaultLabel: 'Claude Agent' },
-    { registryAgent: 'codex-acp', defaultName: 'codex', defaultLabel: 'Codex' },
+    {
+        registryAgent: 'claude-acp',
+        defaultName: 'claude-agent',
+        defaultLabel: 'Claude Agent',
+        recommended: true,
+        detect: { commands: ['claude'] },
+    },
+    { registryAgent: 'codex-acp', defaultName: 'codex', defaultLabel: 'Codex', recommended: true, detect: { commands: ['codex'] } },
+    {
+        registryAgent: 'qoder',
+        defaultName: 'qoder',
+        defaultLabel: 'Qoder',
+        detect: { commands: ['qodercli'] },
+        // The registry still launches 0.2.14, which only reports legacy `models`. The tested native
+        // release reports ACP configOptions for model/mode and accepts session/set_config_option.
+        // Keep registry installs on the same verified runtime as the native production baseline.
+        distribution: { version: '1.1.61', npx: { package: '@qoder-ai/qodercli@1.1.61', args: ['--acp'] } },
+    },
     // `gemini` was here and is deliberately gone. `@google/gemini-cli --acp` now refuses `session/new`
     // outright ("This client is no longer supported for Gemini Code Assist for individuals … migrate
     // to the Antigravity suite"), so recommending it puts an agent in the popover's top tier that
     // cannot open a session for whoever takes the recommendation. It stays in the ACP registry and can
     // still be added by hand from the collapsed section; what is withdrawn is Axom's own endorsement,
     // which is the only thing this file publishes.
+    {
+        registryAgent: 'kimi-code',
+        defaultName: 'kimi-code',
+        defaultLabel: 'Kimi Code',
+        // Kimi Code 发布独立二进制（GitHub release，6 平台 tar.gz，各带 `.sha256`；归档根目录就是 `kimi`，
+        // Windows 是 `kimi.exe`），不依赖本机 Node —— npm 包 `@moonshot-ai/kimi-code` 要 Node >= 22.19，
+        // 会把 Node 版本变成又一个"装好了却起不来"的理由。`acp` 子命令是它的 ACP 服务端；凭据在
+        // `~/.kimi-code`，与用户自己装的那份共用——实测把二进制挪到别的目录照样免登录开会话。
+        // 其余字段照 registry#458 的条目写。
+        supplement: {
+            name: 'Kimi Code',
+            version: '2.1.1',
+            description: "Moonshot AI's next-gen coding agent",
+            repository: 'https://github.com/MoonshotAI/kimi-code',
+            website: 'https://moonshotai.github.io/kimi-code/',
+            authors: ['Moonshot AI'],
+            license: 'MIT',
+            icon: 'https://cdn.agentclientprotocol.com/registry/v1/latest/kimi.svg',
+            distribution: {
+                binary: kimiCodeBinary('2.1.1', {
+                    'darwin-aarch64': ['darwin-arm64', '8c3bad99571b16abd113ab5d511a98a36b852c0d5493991842a67b8c2bc4ecd0'],
+                    'darwin-x86_64': ['darwin-x64', 'f6dc0289112c24119d070f9203d44bcd53580e380819db25b58be65643b75bd4'],
+                    'linux-aarch64': ['linux-arm64', '5c68d74b139b47fb3457f3805a159cdfa942a6a98a159ab158a1baf93b024bbd'],
+                    'linux-x86_64': ['linux-x64', 'b66cc3787bc9dfa6a06761305dc8878f98e7a24f79fa4494c00714229a1486e8'],
+                    'windows-aarch64': ['win32-arm64', '72bb17fef0d165a5f61905ede7e57c552791905d605a778967d054fe702873d4'],
+                    'windows-x86_64': ['win32-x64', '87756a53a9bb0915842d884eaf43f69a06b2e404bcbb05d41c519c12d4b410cb'],
+                }),
+            },
+        },
+        supersedes: ['kimi'],
+        // 官方安装器把二进制放在 `~/.kimi-code/bin`，不一定进了 daemon 看得见的 PATH。
+        detect: {
+            commands: ['kimi'],
+            locations: everyPlatform(['~/.kimi-code/bin/kimi'], ['~/.kimi-code/bin/kimi.exe']),
+        },
+    },
+    {
+        registryAgent: 'command-code',
+        defaultName: 'command-code',
+        defaultLabel: 'Command Code',
+        // registry 没有它。1.66.0 还没有 `acp` 子命令，1.74.3 起有、真机试跑通过。包里有 `cmd`、`cmdc`、
+        // `commandcode`、`command-code` 四个 bin，npx 挑与包名同名的那个。没有 ACP 登录方法，只有一句
+        // 说明（终端里跑 `cmd login`）；凭据在 `~/.commandcode`，与用户自己装的那份共用。npm 上的许可证
+        // 写的是 UNLICENSED（专有）。
+        supplement: {
+            name: 'Command Code',
+            version: '1.74.3',
+            description: 'Command Code, coding agent that continuously learns your coding taste.',
+            website: 'https://commandcode.ai',
+            authors: ['Command Code'],
+            license: 'UNLICENSED',
+            icon: 'https://commandcode.ai/favicon.ico',
+            distribution: { npx: { package: 'command-code@1.74.3', args: ['acp'] } },
+        },
+        detect: { commands: ['command-code', 'commandcode'] },
+    },
+    {
+        registryAgent: 'zcode-acp',
+        defaultName: 'zcode',
+        defaultLabel: 'ZCode',
+        unverified: 'zcode-acp 0.63/0.64 与 ZCode 桌面 3.14.x 不兼容：3.14 不写 ~/.zcode/v2/config.json，模型只剩无授权的 ' +
+            'builtin:bigmodel-coding-plan\\GLM-5.3，首轮 CONFIGURATION_ERROR "Model creation failed"（2026-10-06 两台机器复现）。',
+        // 社区适配器（registry#566、#650 都还没合），驱动的是 ZCode 桌面应用自带的 `zcode app-server`，
+        // 所以 ZCode 本体是前置依赖，而且没有一条我们能替用户跑的安装命令 —— 只能告诉他去装。
+        // 凭据在 `~/.zcode/v2/config.json`，由 ZCode 自己登录写下。Linux 上本体没有固定路径，只认 PATH。
+        supplement: {
+            name: 'ZCode',
+            version: '0.63.0',
+            description: 'Community bridge that drives the real ZCode app-server (GLM) over ACP.',
+            repository: 'https://github.com/william0wang/zcode-acp',
+            website: 'https://github.com/william0wang/zcode-acp',
+            authors: ['William Wang'],
+            license: 'Apache-2.0',
+            icon: 'https://raw.githubusercontent.com/william0wang/zcode-acp/main/registry/zcode-acp/icon.svg',
+            distribution: { npx: { package: 'zcode-acp-server@0.63.0' } },
+        },
+        prerequisite: {
+            label: 'ZCode',
+            detect: {
+                commands: ['zcode'],
+                locations: {
+                    'darwin-aarch64': ['/Applications/ZCode.app/Contents/Resources/glm/zcode.cjs'],
+                    'darwin-x86_64': ['/Applications/ZCode.app/Contents/Resources/glm/zcode.cjs'],
+                    'windows-aarch64': ['%LOCALAPPDATA%/Programs/ZCode/resources/glm/zcode.cjs'],
+                    'windows-x86_64': ['%LOCALAPPDATA%/Programs/ZCode/resources/glm/zcode.cjs'],
+                },
+            },
+            hint: 'Install the ZCode desktop app (https://zcode.z.ai) and sign in once.',
+        },
+    },
     {
         registryAgent: 'pi-acp',
         defaultName: 'pi',
         defaultLabel: 'Pi',
-        dependency: {
-            check: 'pi',
+        recommended: true,
+        prerequisite: {
+            label: 'Pi',
+            detect: { commands: ['pi'] },
             // 不用 `curl -fsSL https://pi.dev/install.sh | sh`：读过那个脚本，它最终跑的就是这一条
             // （`npm install -g --ignore-scripts @earendil-works/pi-coding-agent`），装出来的是同一个
             // npm 包 —— pi 没有原生分发。脚本唯一的增值是 Node 不够新时帮你装 Node，而那一步是交互式的
@@ -22,8 +212,77 @@ export const AXOM_AGENT_CATALOG = [
             requiresNode: '>=22.19.0',
         },
     },
+    // registry 自己的条目（binary .par），我们只补名字与本机检测；`agy` 是 Antigravity 装好后放进 PATH 的命令。
+    { registryAgent: 'antigravity-acp', defaultName: 'google-antigravity', defaultLabel: 'Google Antigravity', detect: { commands: ['agy'] } },
 ];
+/**
+ * Kimi Code 的六个平台归档：GitHub release `@moonshot-ai/kimi-code@<version>` 下的
+ * `kimi-code-<target>.tar.gz`，`sha256` 抄自同名 `.sha256` 资产。版本升级时三样一起换。
+ */
+function kimiCodeBinary(version, targets) {
+    const release = `https://github.com/MoonshotAI/kimi-code/releases/download/@moonshot-ai/kimi-code@${version}`;
+    return Object.fromEntries(Object.entries(targets).map(([triple, [target, sha256]]) => [triple, {
+            archive: `${release}/kimi-code-${target}.tar.gz`,
+            sha256,
+            cmd: triple.startsWith('windows-') ? './kimi.exe' : './kimi',
+            args: ['acp'],
+        }]));
+}
+/** 同一组位置用于全部平台（Windows 三元组用 `windows` 那组）。 */
+function everyPlatform(unix, windows) {
+    return {
+        'darwin-aarch64': unix, 'darwin-x86_64': unix, 'linux-aarch64': unix, 'linux-x86_64': unix,
+        'windows-aarch64': windows, 'windows-x86_64': windows,
+    };
+}
 const BY_ID = new Map(AXOM_AGENT_CATALOG.map((entry) => [entry.registryAgent, entry]));
 export function catalogEntryFor(registryAgent) {
     return BY_ID.get(registryAgent);
 }
+/**
+ * The registry entry as Axom will actually install and launch it: unchanged unless something
+ * overrides it. A distribution replaces the registry's `version` and `distribution` — a runtime.json
+ * override that applies at this registry version first, else this catalog's own. Launch env is merged
+ * under every distribution's own `env` (the registry's declared variables win over ours). Identity
+ * and the registry's own words never move (see the file header).
+ */
+export function applyCatalogOverrides(agent) {
+    const entry = catalogEntryFor(agent.id);
+    const patch = patchOverridesFor(agent.id, agent.version);
+    const pinned = patch.distribution ?? entry?.distribution;
+    const launchEnv = { ...entry?.launchEnv, ...patch.env };
+    let effective = agent;
+    if (pinned) {
+        const { version, ...distribution } = pinned;
+        effective = { ...effective, version, distribution };
+    }
+    if (Object.keys(launchEnv).length) {
+        effective = { ...effective, distribution: withLaunchEnv(effective.distribution, launchEnv) };
+    }
+    return effective;
+}
+/** The registry's list with this catalog's supplements added where the registry lacks them and superseded ids removed. */
+export function withCatalogEntries(agents) {
+    const published = new Set(agents.map((agent) => agent.id));
+    const superseded = new Set(AXOM_AGENT_CATALOG.flatMap((entry) => entry.supersedes ?? []));
+    const supplements = AXOM_AGENT_CATALOG.flatMap((entry) => entry.supplement && !published.has(entry.registryAgent) ? [{ ...entry.supplement, id: entry.registryAgent }] : []);
+    return [...agents.filter((agent) => !superseded.has(agent.id)), ...supplements];
+}
+function withLaunchEnv(distribution, launchEnv) {
+    const under = (target) => ({ ...target, env: { ...launchEnv, ...(target.env ?? {}) } });
+    return {
+        ...distribution,
+        ...(distribution.npx && { npx: under(distribution.npx) }),
+        ...(distribution.uvx && { uvx: under(distribution.uvx) }),
+        ...(distribution.binary && {
+            binary: Object.fromEntries(Object.entries(distribution.binary).map(([platform, target]) => [platform, target && under(target)])),
+        }),
+    };
+}
+/**
+ * {@link withCatalogEntries} then {@link applyCatalogOverrides} over a whole registry. `AcpAgents` reads the registry through this
+ * and nothing else, so roster, install, launch and update all see the same effective entries.
+ */
+export function withCatalogOverrides(registry) {
+    return { load: async () => withCatalogEntries(await registry.load()).map(applyCatalogOverrides) };
+}

package/dist/workstation/acp/registry/detect.js

@@ -0,0 +1,55 @@
+/**
+ * 本地检测：这台机器上**用户自己**有没有装某个 agent（或它的前置依赖）。
+ *
+ * ## 它回答的不是"Axom 装好了没有"
+ *
+ * Axom 启动的一律是自己托管的那份（npx 缓存、`uv tool dir`、`<config dir>/acp-adapters`），
+ * 那是 `acpAgents.ts` 的 `adapterInstalled` 的事。这里看的是用户在终端里用的那份：PATH 上的命令、
+ * 厂商安装器放下的固定文件。它只有两个用途（见 `catalog.ts` 文件头）：
+ *
+ * - **推荐信号**：检测到 = 这台机器的用户在用它，于是设置页把它排进推荐位，原因写"本机在用"。
+ * - **前置依赖**：ZCode、Pi 这类适配器自己不带引擎，检测不到本体就起不来。
+ *
+ * ## 只看文件在不在，不起进程
+ *
+ * 与 `installProbe.ts` 的 `findOnPath` 同一条规矩：roster 一次要对 registry 里全部 agent 回答，
+ * 一个会执行东西的探针就是每次扫描几十个子进程。`--version` 回答的是另一个更贵的问题。
+ */
+import { statSync } from 'node:fs';
+import path from 'node:path';
+import { findOnPath } from '../installProbe.js';
+/**
+ * 按 `spec` 在这台机器上找：PATH 上的任一命令，或本机三元组下的任一文件位置。
+ *
+ * `triple` 是 `binaryInstall.ts` 的 `platformTriple` 算出来的本机三元组；落在 registry 六个三元组
+ * 之外的机器传 `undefined`，此时只看 `commands`。
+ */
+export function detected(spec, probe, triple) {
+    if (!spec)
+        return false;
+    if (spec.commands?.some((command) => findOnPath(command, probe) !== undefined))
+        return true;
+    const locations = triple ? spec.locations?.[triple] : undefined;
+    return locations?.some((location) => {
+        const resolved = resolveLocation(location, probe);
+        return resolved !== undefined && isFile(resolved);
+    }) ?? false;
+}
+/** 展开 `~/` 与 `%LOCALAPPDATA%/`；对应的目录未知时返回 `undefined`（这条线索查不了，不是命中）。 */
+export function resolveLocation(location, probe) {
+    if (location.startsWith('~/'))
+        return probe.home ? path.join(probe.home, location.slice(2)) : undefined;
+    if (location.startsWith('%LOCALAPPDATA%/')) {
+        return probe.localAppData ? path.join(probe.localAppData, location.slice('%LOCALAPPDATA%/'.length)) : undefined;
+    }
+    return location;
+}
+// `statSync` 而不是 `lstatSync`：与 `findOnPath` 同理，厂商安装器常放符号链接。
+function isFile(candidate) {
+    try {
+        return statSync(candidate).isFile();
+    }
+    catch {
+        return false;
+    }
+}

package/dist/workstation/acp/sessionScope.js

@@ -0,0 +1,19 @@
+import { SessionMapperState } from './sessionUpdateMapper.js';
+export function scopeKey(scope) {
+    return JSON.stringify([scope.rootRuntimeId, scope.nativeSessionId]);
+}
+export class SessionMapperScopes {
+    create;
+    states = new Map();
+    constructor(create = () => new SessionMapperState()) {
+        this.create = create;
+    }
+    get(scope) {
+        const key = scopeKey(scope);
+        let state = this.states.get(key);
+        if (!state)
+            this.states.set(key, state = this.create(scope));
+        return state;
+    }
+    clear() { this.states.clear(); }
+}

package/dist/workstation/acp/sessionUpdateMapper.js

@@ -1,3 +1,4 @@
+import { codexActivityRaw } from './activityReporting.js';
 /**
  * One session's memory, and the reason this file is no longer stateless: **what this session has
  * already been told**, for the two branches that cannot answer a frame from the frame alone.
@@ -30,7 +31,22 @@
  * already (every call's `rawInput`/`rawOutput` is journaled), so there is no eviction here.
  */
 export class SessionMapperState {
+    onActivityReported;
     byId = new Map();
+    /**
+     * Where an agent-reported activity-state push (today, only `codexActivityRaw`'s extraction of
+     * `session_info_update._meta.codex.threadStatus`) actually goes once {@link reportActivity} is
+     * called — `agentSessions.ts`'s job, not this file's: this module stays "zero IO" (see the file
+     * doc comment) by taking the effect as a constructor dependency rather than reaching for a
+     * socket itself.
+     *
+     * Defaults to a no-op so every existing `new SessionMapperState()` — the tests, `adoption.ts`'s
+     * replay path, which has no live connection to report anything on — keeps compiling and keeps
+     * doing nothing, exactly as it always has.
+     */
+    constructor(onActivityReported = () => { }) {
+        this.onActivityReported = onActivityReported;
+    }
     /**
      * The agent queue depth this session has already reported to the server.
      *
@@ -97,6 +113,16 @@ export class SessionMapperState {
         this.lastReportedQueueDepth = depth;
         return true;
     }
+    /**
+     * One agent-reported activity-state push, vendor-verbatim. Not a `WireEvent` and never routed
+     * through {@link mapSessionUpdate}'s return value — activity is a level, not an edge (see the
+     * `agent_session_state` frame's own doc comment in `protocol/agent.ts`), so it must not become a
+     * durable item, must not be journaled and must not advance any seq. Forwarded to whatever
+     * {@link onActivityReported} this instance was constructed with.
+     */
+    reportActivity(raw) {
+        this.onActivityReported(raw);
+    }
     /** Remember what this call is called. Later updates that carry no `name` fall back to it. */
     record(toolCallId, name) {
         if (name)
@@ -136,7 +162,7 @@ function compact(value) {
     return Object.fromEntries(Object.entries(value).filter(([, v]) => v !== undefined));
 }
 /**
- * `ToolCall.locations` → the wire `tool_call.locations` shape; omitted entirely when there are none.
+ * `ToolCall.locations` → the wire `tool_call.locations` shape; [] explicitly clears a snapshot.
  *
  * An identity copy of ACP's `ToolCallLocation` (`types.gen.d.ts:581`), which is `{path, line?}` —
  * `line` is `number | null | undefined` (`:586-589`) and used to be dropped here, which cost the
@@ -145,7 +171,7 @@ function compact(value) {
  * enclosing payload.
  */
 function mapLocations(locations) {
-    if (!locations || locations.length === 0)
+    if (locations == null)
         return undefined;
     return locations.map((location) => compact({ path: location.path, line: location.line ?? undefined }));
 }
@@ -166,7 +192,7 @@ function toolCallCreatedEvent(update, state) {
             // only field guaranteed to give the card a name.
             name: update.name ?? update.title,
             toolCallId: update.toolCallId,
-            rawInput: update.rawInput,
+            rawInput: update.rawInput ?? undefined,
             kind: mapToolKind(update.kind),
             title: update.title,
             locations: mapLocations(update.locations),
@@ -239,16 +265,10 @@ function toolCallUpdateEvent(update, state) {
             title: update.title ?? undefined,
             kind: update.kind ?? undefined,
             status: update.status ?? undefined,
-            // An empty array is omitted rather than sent, and the behaviour is deliberate now that the
-            // card's fold *does* honour ACP's "replace the content collection": `applyChunks` treats an
-            // empty chunk list as "unchanged" at every call site, never as a clear. So an empty array
-            // carries nothing either way — and the server drops it on the way back out anyway
-            // (`TimelineEvent.ToolCallUpdated.payload` only writes `content` when it is non-empty), which
-            // is why sending one could not express a clear even if a consumer wanted to act on it.
-            content: update.content && update.content.length > 0 ? update.content : undefined,
+            content: update.content == null ? undefined : update.content,
             locations: mapLocations(update.locations),
-            rawInput: update.rawInput,
-            rawOutput: update.rawOutput,
+            rawInput: update.rawInput ?? undefined,
+            rawOutput: update.rawOutput ?? undefined,
             // See the doc comment above: ACP's extension slot, copied verbatim and read by nothing *here*
             // (the server's `decodeToolUpdate` does read it, also verbatim).
             _meta: update._meta ?? undefined,
@@ -257,16 +277,11 @@ function toolCallUpdateEvent(update, state) {
 }
 function mapToolCallEvents(update, state) {
     const events = [toolCallCreatedEvent(update, state)];
-    // ACP permits a `tool_call` to arrive already finished — the agent reporting a call it both
-    // started and completed in one notification, with no separate `tool_call_update` at all. A card
-    // only ever leaves "Running" on an update reporting a non-pending status
-    // (`WorkTimelineTools.foldToolUpdate`'s outcome branch), and the creation event carries no status,
-    // so without this second event an already-terminal call would render as permanently "Running".
-    //
+    // Creation carries initial update fields too. Emit them immediately under the same id so pending
+    // content and status, as well as an already-terminal result, survive a missing later update.
     // `ToolCall` is structurally a `ToolCallUpdate` (every field of the latter, with `title` and `kind`
-    // merely narrower), so the same function emits both — the two cannot drift into disagreeing about
-    // what a terminal update looks like.
-    if (update.status === 'completed' || update.status === 'failed') {
+    // merely narrower), so the same function emits both.
+    if (update.status != null || update.content != null || update.rawOutput != null) {
         events.push(toolCallUpdateEvent(update, state));
     }
     return events;
@@ -476,6 +491,9 @@ export function mapSessionUpdate(update, state) {
             const queueNotice = agentQueueNotice(update._meta, state);
             if (queueNotice)
                 events.push(queueNotice);
+            const activityRaw = codexActivityRaw(update._meta);
+            if (activityRaw)
+                state.reportActivity(activityRaw);
             return events;
         }
         case 'usage_update':