[grok-copresence][P0] 现在新起/重启任何共存节点都会被自己的 pre-spawn 审计拒掉 —— 生成侧写绝对路径，审计侧要求裸 "bun"

[vansin]

一句话

产品自己生成的 config.toml 里写的是绝对路径，而它自己的 pre-spawn 审计要求那一格恰好是裸字符串 "bun"。
两者由同一份代码在同一次启动里产生，不可能同时满足 ⇒ 现在 prepare 出来的共存节点，
过不了自己的审计。

证据链（四段，每段都可复验）

① 生成侧：解析器永远不可能返回裸命令名

agent-node/src/runtime/grok-build-cli-home.ts:60：

export function resolveGrokCommhubMcpCommand(command: string, pathEnv: string): string {
  const candidates = isAbsolute(command) ? [command]
    : pathEnv.split(delimiter).filter(Boolean).map((directory) => resolve(directory, command));
  for (const candidate of candidates) {
    try {
      const canonical = realpathSync(candidate);
      if (!statSync(canonical).isFile()) continue;
      accessSync(canonical, constants.X_OK);
      return canonical;            // ← 唯一的成功返回，realpath 之后的绝对路径
    } catch {}
  }
  throw new Error("grok copresence CommHub MCP command could not be resolved or executed");
}

只有两种出口：绝对规范路径，或抛错。 裸 "bun" 不在其中。

② 那个值被原样写进 config.toml

agent-node/src/cli.ts:3682：

const commhubMcpCommand = resolveGrokCommhubMcpCommand(process.env.BUN_BIN || "bun", process.env.PATH || "");

agent-node/src/runtime/grok-build-cli-home.ts:1471：

`command = ${JSON.stringify(commhubMcp.command)}`,

（同一文件 :1067 还额外强制 realpathSync(command) === command，也就是必须 canonical。）

③ 真 grok 0.2.93 把它原样报成 target（实测，不是推断）

在容器里装钉死版本、--network none 离线跑（宿主那份是 1.0.5，且其符号链接被 63 个在跑节点共用，没有动）：

容器内 grok --version → grok 0.2.93 (f00f96316d)
config.toml: command = "/usr/local/bin/fake-bun"

$ grok inspect --json
"mcpServers": [{
  "name": "commhub", "transport": "stdio",
  "target": "/usr/local/bin/fake-bun",
  "source": { "type": "configToml", "path": "/tmp/gh/config.toml" }
}]

⇒ target = config.toml 的 command，逐字，绝对路径。

④ 审计要求它恰好是裸 "bun"

agent-node/src/runtime/grok-copresence/runtime.ts:550：

|| commhubRecord.target !== "bun"

而 beforeSpawn 是无条件挂上的（agent-node/src/cli.ts:3844）：

beforeSpawn: () => auditAndPrepareRuntime().env,

所以每次 spawn 都跑这条审计，失败即 GrokCopresenceFailure: grok copresence pre-spawn audit failed。

磁盘上的现状与这条推论一致

本机 ~/.anet-grok/node-*/config.toml（只读了 command 那一行）：

node-47d475f619473b592af34838   command = "bun"                                    ← 旧代码写的，能过审计
node-a2f3e13fd1cab3e4f498a3a3   command = "bun"
node-c05a2744ac212c3f0c4ab709   command = "bun"
node-1a793d6b1274fe11f641001c   command = "/home/vansin/.nvm/…/bun/bin/bun.exe"    ← 绝对路径，按 :550 会被拒
其余 2 个没有 [mcp_servers.commhub] 段

node-1a793d6b… 的 session 目录是 %2Fhome%2Fvansin%2Fgrok-commdog-workspace ⇒ 通信狗。

而当前 5 个 grok 共存节点（A站狗 / P站狗 / 通信狗 / 指挥狗 / TM宿舍狗）全部 status=offline。

🔴 我不声称这就是每一个节点 offline 的原因 —— 那需要各自的启动日志。
上面成立的是一条结构性推论：用当前代码 prepare 出来的配置，必然过不了当前代码的审计。
三个 command = "bun" 是历史遗留（旧版本写的），它们只要不重新 prepare 就还能跑；
一旦重启并重写 config.toml，就会变成绝对路径，然后被拒。

影响范围

• 版本上：那行审计由 8167c494（2026-08-04）引入；@sleep2agi/agent-node@2.5.0-preview.31
  发布于 2026-08-12 ⇒ 在跑的 preview 含这行。main 同样含。
• 也就是说 main 和在跑的 preview 都在这个状态，不是「main 已修、线上未部署」。

不要按直觉修

有两个方向，选错会把现在还能跑的那三个也弄坏：

1. 把审计改成「和解析后的绝对命令比」（= 被我从 fix(grok): 把 #867 落到 main —— 含 #883(P0) 点名的修复，并修掉它自带的一处能力边界回归 #1010 摘掉的 7914755a 的方向）——
   对新配置正确，但会立刻拒掉那三个 command = "bun" 的旧配置；
2. 让审计同时接受两种形态（把 target 也按 PATH 解析一次再比）——
   兼容旧配置，代价是审计逻辑变复杂。

⚠️ 还有一件必须先确认的：那三个旧配置是「历史遗留」还是「某条代码路径仍会写裸 bun」。
如果是后者，方向 1 会周期性地反复弄坏节点。我没有查到写裸 "bun" 的路径
（resolveGrokCommhubMcpCommand 排除了这个可能），但**「我没找到」不等于「不存在」**。

与 #1011 的关系

#1011 是同一根因的另一半（夹具把 target 写死成 "bun"，所以这个矛盾在 CI 里永远看不见）。
本条记的是后果：产品起不来。两条一起看才完整。

[vansin]

🔴 更正：这是今天我自己造成的回归，不是历史遗留

本条正文我把三个 command = "bun" 的旧配置写成「历史遗留」，并说「我没查到写裸 bun 的路径」。
查到了 —— 就在几个小时前的 main 上，而且是我把它改掉的。

时间线（可复验）

git log -S 'export function resolveGrokCommhubMcpCommand' -- agent-node/src/runtime/grok-build-cli-home.ts
→ 89a6164e 2026-08-18 fix(grok): 把 #825 的 MCP 就绪 fail-closed 落到 main …… (#1004)

git log -S 'command = ${JSON.stringify(commhubMcp.command)}' -- agent-node/src/runtime/grok-build-cli-home.ts
→ 89a6164e   （同一个提交，且只有这一个）

89a6164e^（也就是今天之前的 main）那一段原文是：

      "[mcp_servers.commhub]",
      'command = "bun"',                                        ← 硬编码裸命令
      `args = [${JSON.stringify(commhubMcp.serverPath)}]`,

⇒ 在今天之前，生成侧写裸 "bun"，审计要求裸 "bun" —— 两者是一致的、能工作的。

我做了什么

1. fix(grok): 把 #825 的 MCP 就绪 fail-closed 落到 main（rebase + 补两处今天新门抓到的） #1004（89a6164e，今天）：把 fix(grok): fail closed when CommHub MCP is not ready #825 的工作落到 main，其中包含
   resolveGrokCommhubMcpCommand，生成侧从 'command = "bun"' 变成解析后的绝对路径；
2. fix(grok): 把 #867 落到 main —— 含 #883(P0) 点名的修复，并修掉它自带的一处能力边界回归 #1010（f1208449，今天）：我把 7914755a fix(grok): bind MCP audit to resolved Bun path
   外科式摘掉了 —— 理由是它让 test813 的 canonical-Bun 路径起不来。

🔴 而 7914755a 正是这次改动的另一半：审计侧。 我落了生成侧、摘了审计侧，
于是 main 现在是一对不匹配的半边 —— 这个不匹配是我制造的。

我在 #1010 里摘它时给的理由（「它让产品拒绝自己生成的配置」）方向正好反了：
真正让审计拒绝配置的，是缺了它。当时看起来是它导致红，实际是
夹具把 target 写死成 "bun"（#1011），于是「审计+夹具」自洽、
而「审计+真 grok」不自洽 —— 我读到的红来自夹具，不来自产品。

这也修正了本条正文里两个判断

• 「那三个裸 bun 是历史遗留，重启就会变成绝对路径然后被拒」 —— 前半对，后半的推论要改：
  beforeSpawn: () => auditAndPrepareRuntime().env 是先 prepare 再审计，
  prepare 会重写 config.toml。所以只要审计那半也落地，
  「重写成绝对路径 + 审计比绝对路径」是自洽的，不会拒。
• 「改成和绝对命令比会立刻拒掉那三个旧配置」 —— 错的，同上：那三个配置会在 prepare 时被重写。
  我当时把 config.toml 当成了持久输入，它其实是每次 prepare 的产物。

因此修法是确定的，不再是二选一

① 重新落地审计那半（7914755a 的方向：和解析后的绝对命令比）
② 同时修 fake-grok.mjs：target 从它自己声称的 configToml 里读 command，而不是写死 "bun"
   （不修它，①会再一次「看起来让 test813 红」，而红的仍然是夹具）

两件必须一起落，分开落任一半都会让 main 停在不一致状态 —— 这正是我今天犯的错。

严重度不变

main 与在跑的 preview.31 都含审计那半吗？—— 审计那半（target !== "bun"）从 08-04 就在；
生成侧的绝对路径是今天才进 main 的。所以：

• 在跑的 preview.31（08-12 发布）：生成侧还是裸 "bun" ⇒ 和审计一致，它们是好的；
• main（今天起）：生成侧绝对路径 + 审计要裸 "bun" ⇒ 不一致，下一次发版会把这个带出去。

⇒ 本条的严重度从「在跑的节点起不来」修正为
「main 已经坏了，但还没发出去；在修好之前不要从 main 发 preview」。
这比原来的判断轻，但紧迫性不变 —— 因为第 11 项要做的正是「发 preview + 重启」。

[vansin]

已由 #1017 修掉，合入 origin/main = b732d5ef。

先更正一句归因（我自己错的）

我最初把那三份 command = "bun" 的配置说成「历史遗留」，还说找不到写裸 bun 的代码路径。
git log -S 打回来的是 89a6164e（就是我今天的 #1004）：它引入了解析器和那行生成语句，
而 89a6164e^ 那行还是 'command = "bun"'。所以这个不一致是我造成的 ——
我把生成侧（#1004）落了，审计侧（7914755a / #1010）漏了，两半错开一天。

修法

审计函数现在接一个期望值，两边都归一化后再比，而不是硬写字面量 "bun"：

agent-node/src/runtime/grok-copresence/runtime.ts:564
  || resolve(String(commhubRecord.target || "")) !== resolve(expectedCommhubCommand)

签名带默认值 expectedCommhubCommand = "bun"，只为没迁移的调用方保留旧行为；
真正的调用侧（agent-node/src/cli.ts）已经把解析出来的绝对路径传进去了。

内容复验（squash 之后 git cherry 不成立，所以按内容数）

agent-node/src/runtime/grok-copresence/runtime.ts   expectedCommhubCommand            命中 2
agent-node/src/runtime/grok-copresence/runtime.ts   resolve(expectedCommhubCommand)   命中 1
agent-node/src/cli.ts                               commhubMcpCommand,                命中 2
agent-node/src/runtime/grok-copresence/runtime.test.ts  /opt/anet/bin/bun              命中 1

最后那条是把这个 issue 本身钉成回归测试：绝对路径 + 相同期望值 → 不抛；
绝对路径 + 不同期望值 → 抛；裸 bun 的 inspection + 绝对路径期望值 → 抛（就是本 issue 的形状）。

另外纠正一个我一开始的误解：config.toml 不是持久输入。beforeSpawn 是先重写它再审计的，
所以「线上那份 config 里写的是什么」不参与判定。