fix(grok): preserve safe TUI composer navigation

[vansin]

What changed

• preserve safe Left/Right/Home/End/Delete TUI composer editing without weakening the immutable approval-mode boundary
• return arbitration to idle after a blocked slash command so the next Dashboard task is not stranded
• retire a terminal co-presence runtime before the next task instead of caching runtime_closed forever
• bind the inspected CommHub MCP target to the exact pre-resolved Bun executable path
• correlate batched exact-profile automatic permissions as a bounded multiset, including duplicate tools and out-of-request-order resolutions
• keep manual overlap, unmatched lifecycle events, overflow, and unresolved terminal completion fail-closed

Root cause

The live 通信狗 incidents had three layers. Its original x-search profile denied a repository tool that Grok nevertheless auto-resolved; the bridge correctly failed closed, but agent-node cached that terminal runtime. The repo-read pilot then exposed an obsolete literal-bun audit comparison. After those were fixed, the real Grok event stream emitted three automatic permission requests first (search_tool, list_dir, search_tool) and resolved them later as (search_tool, search_tool, list_dir). A scalar pending-permission slot misclassified this valid batched lifecycle as an approval-boundary violation, after which six queued tasks failed within seconds.

Frozen coordinates

• product source: b830403b82a97a98ec004e59c86eb294ddfd1771
• report-only head: 19af299adea89cb6296a5d3971b574ad88e2c423
• exact candidate image: sha256:261ade0fd44147370df56a7377f409c840f3e65a07aa472174e7761184b45ecb
• candidate agent-node bundle SHA-256: 5c0d5cbcfb0350af1eb27e78de1ccd5902c5ba22be732df415fe26851c269a45

This Draft remains stacked on the existing Grok co-presence work. It does not publish npm or merge into the base branch.

Validation

• the new batched-permission fixture was witnessed red on the previous runtime with duplicate preview automatic permission request
• exact-source focused Docker runtime/profile/near-miss layer: 84 pass / 0 fail / 3 files
• exact-source full test725 domain: 1288 pass / 0 fail / 92 files; named mutation red; RESULT: PASS
• exact source built successfully into the candidate runtime and produced the bundle SHA above
• single-node pilot retained exact tmux session 通信狗 with 0:node and 1:tui; it reached TUI input-ready, CommHub registration, and SSE, and Hub reports idle with zero pending/in-flight tasks
• no production task was synthesized, retried, or sent during recovery

Full evidence: docs/tests/report-grok-copresence-fatal-recovery-7914755a.txt.

Honest limits

• owner-origin Dashboard behavior remains the final UAT; task traffic stays paused until that explicit test
• /model remains intentionally blocked: the current FIFO protocol cannot yet prove when Grok's interactive model picker has returned to the composer. Persisted model changes still require a controlled config update and restart.

[vansin]

Draft,不合,只留 review。这个 PR 改的是 isGrokPreviewAutomaticResolution —— 决定「这次自动放行算不算被认可的例外」的那个谓词。安全相关,所以我逐条读了。

🔴 一、那条身份比对,在两个分支下分别是恒假和恒真

改后的判据里有这一条:

&& requestId === `tool:${input.requestTool}`

其中两个值都来自同一个 event:

const requestId = lifecyclePermissionIdentity(event);   // :3286
const eventTool = lifecyclePermissionTool(event);       // :2122
… isGrokPreviewAutomaticResolution({ requestTool: eventTool, … })

而 lifecyclePermissionIdentity 是这样的:

if (requestId /* event.request_id | event.requestId */) return `id:${requestId}`;
return toolName ? `tool:${toolName}` : null;

⇒ 分两种情况:

event 带 request_id 吗	requestId	与 tool:${requestTool} 比
带	id:…	永远不相等 ⇒ 谓词恒假
不带	tool:<tool_name>	而 requestTool 就是同一个 tool_name ⇒ 恒真

也就是说:这一条在能通过的那个分支里,比较的是同一个 event 里的同一个字段和它自己。它贡献 0。

🔴 而它看起来像是在做「把这次 resolution 和当初那个 request 对上」。 这是一条读起来像身份校验、实际不做校验的断言 —— 它的危险不在于错,在于它占住了那个位置,让后来的人以为那里有一道校验。

二、被它替换掉的那条,是真的身份绑定

改之前:

-    && input.activeRequestId === `tool:${input.requestTool}`
-    && requestId === input.activeRequestId

而当时 requestTool 传的是 this.activePermissionExactPreviewTool(跟踪状态),这次改成了 eventTool(事件自带)(:669-671)。

⇒ 旧版第二个合取项 requestId(来自 event) === activeRequestId(来自跟踪状态) 是一次真的 event ↔ state 交叉校验。

新版把它换成了 pendingRequestCount > 0 —— 一个计数。

🔴 计数不能回答「这次 resolution 属于哪一个 request」。 而这个 PR 的动机恰恰是并发/重叠的 request(测试名:exact search_tool then use_tool in a human turn)—— 在重叠场景下,「有请求挂着」和「挂着的正是这一个」的区别最大,而新版只保留了前者。

我理解旧版单个 activeRequestId 确实建模不了重叠 —— 但出路应该是把它升级成一个「挂起中的 id 集合」并按 id 匹配,而不是降级成计数。 现在 pendingAutomaticPermissions 已经是一个 Map<tool, count>;把它做成 Map<tool, Set<requestId>> 的改动量不大,而且能把上面那条恒真/恒假的比较变成一条真的校验。

三、waitingHuman 的极性被反了,想确认这是有意的

-    && input.waitingHuman
+    && !input.waitingHuman

注释给了理由(process 级 --always-approve 属于共享的 grok 进程、不属于 anet 的逻辑 turn owner,所以人类 turn 也会产生同样的自动 resolution 生命周期)。

但这不是放宽,是换了一边:旧版要求「正在等人」,新版要求「不在等人」。原来被这条接住的那一类(确实在等人时到达的自动 resolution),现在会被判成不是认可的例外。

⚠️ 想确认:那一类现在走哪条路? 如果落到 fail-closed 的分支上,那是安全的(只是更严);如果落到别的分支,需要说明。极性翻转在一个安全谓词里,值得在注释里单独写一句「翻转之后,原来那一侧现在的归宿是 X」 —— 否则下一个读的人只能看到「有理由」,看不到「另一侧去哪了」。

四、值得肯定的

runtime-retirement.ts(+29/-0)带了自己的测试(+62),而且 report-grok-copresence-safe-navigation-mutation-*.txt 是单独的变异报告 —— 把「跑绿了」和「变异能打红」分成两份证据存,这个习惯是对的。

---

总结:①那条身份比对建议要么改成真的按 id 匹配、要么删掉(留着比删掉更坏,因为它占位);②pendingRequestCount 建议升级回按 id 的集合;③极性翻转补一句「另一侧的归宿」。三条都不阻塞你继续往下做,但①我认为该在这个 PR 里解决 —— 它是这次改动引入的,不是既有债。

[vansin]

这条的内容已落到 main（#1010，f1208449），因此关闭

没有 force-push 这条分支。 落地方式：git rebase --onto origin/main <#830-head> <#867-head>，
再从我自己的分支发 PR。grok 栈四层至此全部落地：

#825  #1004 → main 89a6164e   已关闭
#826  #1006 → main c85dca96   已关闭
#830  #1008 → main 526163cd   已关闭
#867  #1010 → main f1208449   本条

按内容验，并逐条解释每一处差异

文件	新增行	在 main 上找不到
agent-node/src/runtime/grok-copresence/runtime.ts	136	2
agent-node/src/runtime/grok-copresence/runtime.test.ts	120	5
agent-node/src/runtime/grok-copresence/runtime-retirement.ts	27	0
agent-node/src/runtime/grok-copresence/runtime-retirement.test.ts	58	0
agent-node/src/cli.ts	19	5
docs/tests/report-grok-copresence-safe-navigation-a9df8dba.txt	356	0
docs/tests/report-grok-copresence-fatal-recovery-7914755a.txt	102	3
其余 3 个文件	—	0

每一处「找不到」都是我有意为之的，逐条列出来：

cli.ts (5)
  import { retireStoppedGrokCopresenceRuntime } from "./runtime/grok-copresence/runtime-retirement";
     → 改成了动态 import（见下「能力边界回归」）
  assertGrokCopresenceApprovalOwnership( / inspection, / auditRuntime.grokCliHome.home, / commhubMcpCommand,
     → 来自被摘掉的 7914755a

runtime.ts (2)
  expectedCommhubCommand = "bun",
  || resolve(String(commhubRecord.target || "")) !== resolve(expectedCommhubCommand)
     → 来自被摘掉的 7914755a

report-…-fatal-recovery (3)
  previous runtime: /home/vansin/.commhub/…   ×3
     → 按 home-path-baseline 那道门的要求脱敏成 ~/，证据部分一字未动

没有一处无法解释的丢失。

落地时改了三处，两处是它自带的问题

1. 🔴 能力边界回归（copresence-profile-pin 抓到）

本分支加了一条静态 import：

import { retireStoppedGrokCopresenceRuntime } from "./runtime/grok-copresence/runtime-retirement";

ESM 静态 import 是提升的 —— 被导入模块的顶层在 cli.ts 第一条语句之前执行，
于是 policy.ts:22 的 readPinnedGrokCopresenceCapabilityProfile() 读到的是
ambient 环境变量，而不是启动时从节点配置钉下来的档位。能力档位就此可被环境变量绕过。
改成动态 import 放在调用点（钉档位之后）：static_imports 1 → 0，dynamic_imports 2 → 3。

顺带查「同样的危害还有没有别的路径」，发现那道门本身有个可绕过的缺口
（传递静态 import），已带实测假绿开在 #1009，未在本次顺手改。

2. 摘掉 7914755a（CI 上真红）

doc source-pin floor (Docker) 红了：

FAIL: canonical-Bun product path did not reach TUI readiness
GrokCopresenceFailure: grok copresence pre-spawn audit failed:
  grok copresence refuses any MCP server except its runtime-owned commhub stdio server
  failureCode: 'spawn_audit'

根因：生成配置那侧用 realpathSync()（解析符号链接），7914755a 改后的审计侧用
resolve()（不解析）。容器里 bun 是符号链接 ⇒ 节点拒绝了自己刚生成的配置。
外科式只摘这一个提交，其余 7 个照落。它要解决的问题是真的（裸 "bun" 比较挡不住
指向别处的 bun），已带证据开在 #1011。

3. 公开仓真人 home 路径 + 行号 pin

见上表。

这条修了什么（已按内容核过，不是看标题猜的）

• [grok-copresence] 按一次方向键，这一行就永远发不出去了（且提示语谎称是斜杠命令） #881（方向键让这行永远发不出去）：把导航拆成 history / viewport，
  只有 history 触发 blocked 警告，方向键改为写穿。main 上已可见。
• [grok-copresence][P0] 空 composer 上的回车永久死锁节点（通信狗实例，产品内无恢复路径） #883（P0） 正文点名的 b830403b fix(grok): correlate batched automatic permissions
  与 bf0d3134 fix(grok): recover after fatal copresence boundary 都已落 main。
  ⚠️ 但合进 main ≠ 上线 —— 在跑的节点仍需发新 preview 并重启才会拿到，已在 [grok-copresence][P0] 空 composer 上的回车永久死锁节点（通信狗实例，产品内无恢复路径） #883 写明。