Subagent and Workflow child preflight fails when pi-intercom is active in the parent

[thimpeng]

问题 / Problem

同时启用 OpenPI 和 pi-intercom 后，OpenPI 原生 Subagent 与 Workflow child 会在首次模型请求前失败：

Child tool preflight failed: requested tool "intercom" is unavailable after child extensions initialized.

这会使所有继承父会话工具面的 child 无法启动。更换 explorer、reviewer 等内置 agent type，或不指定 agent type，结果相同。

Related to #455.

复现 / Reproduction

1. 在 Pi 中安装并启用当前版本的 @tt-a1i/openpi 与 pi-intercom。
2. 重启或 reload，使父会话同时具有 OpenPI 的 Subagent/Workflow 工具和 intercom 工具。
3. 调用一个普通的 subagent_spawn，或运行包含 agent() 的 Workflow。
4. Child 在模型调用前被 preflight 拒绝。

复现版本：

• Pi 0.85.1
• @tt-a1i/openpi 0.8.1
• pi-intercom 0.13.0
• Node.js 26.0.0

预期行为 / Expected behavior

• OpenPI child 可以正常启动。
• intercom 不进入并发的 in-process child。
• 父会话中的 intercom 保持可用。

实际行为 / Actual behavior

OpenPI 把父会话当前启用的 intercom 加入 child 请求工具列表，但 child resource loading 又按设计移除了 pi-intercom。扩展绑定后的工具检查因此把 intercom 判为缺失并终止启动。未发生模型请求。

初步定位 / Analysis

当前 extensions/shared/child-session.ts 中：

1. blockedPackageSources() 与 createEphemeralChildSettings() 会从 child settings 移除 pi-intercom。源码注释说明，这是为了避免多个并发 in-process child 通过共享 process.env 串接 session identity。这一安全边界是合理的。
2. inheritedChildToolAllowlist(pi.getActiveTools(), roleTools) 继承父会话的 active tools。
3. effectiveChildToolAllowlist() 只过滤 CHILD_EXCLUDED_TOOL_NAMES；intercom 不在其中，因此仍留在 requested tools。
4. bindChildSessionExtensions() 随后发现 child registry 没有 intercom，触发上述 preflight error。

Direct Subagent 与 Workflow 共用这组 helper，因此两条路径都会受影响。

建议的最小修复 / Suggested minimal fix

在从父会话投影 child tools 时，把 intercom 作为 child-ineligible tool 过滤掉，同时继续从 child resources 中排除 pi-intercom，并保持父会话工具不变。资源排除与 requested-tool preflight 最好共享同一 child-ineligible policy，避免“扩展按设计移除，但工具仍被声明为必需”的不一致。

建议增加两个回归测试：

• 父会话启用 intercom 时，Direct Subagent 能启动，child 中无 intercom，父会话仍保留该工具。
• 相同条件下，Workflow agent() 能启动并保持相同边界。

隐私说明 / Privacy

此报告未包含凭据、用户目录、项目路径、项目名称、session ID、会话内容、Provider/模型身份或私有日志。

[naivezip]

你好！
该问题与 #483 为完全相同的重复问题，分析结论与建议的修复方案完全一致。
目前修复代码及相关测试均已完成，并已提交至 PR #494：#494

PR #494 修复要点：

1. 将 intercom 移出子会话工具面：在 extensions/shared/child-session.ts 的 CHILD_EXCLUDED_TOOL_NAMES 中添加 "intercom"。这保证了 inheritedChildToolAllowlist、effectiveChildToolAllowlist 和 childToolPolicy 在构造子代理与 Workflow 工具集合时，始终将 intercom 自动过滤排除。
2. 保持安全隔离边界：blockedPackageSources() 继续将 pi-intercom 排除在子会话资源与扩展配置之外，防止同进程并发子会话通过 process.env 产生身份串号，保留了 setup: 移除 OpenPI 对 pi-intercom 的主动安装与配置职责 #128 的安全约定。
3. 漂移守卫与回归测试：
   • 更新了 child-session.test.ts 的 fail-closed 漂移守卫和 tool-surface.test.ts 的工具目录校验。
   • 新增了回归用例：验证父会话激活 intercom 时，子会话继承列表自动丢弃 intercom，且 bindChildSessionExtensions 预检正常通过。
   • 验证了 Direct Subagent 和 Workflow 执行套件均能顺利通过。

[tt-a1i]

新证据（print-mode + 与 #483 同因）

同意：这是 #483 的重复，机制同属 child-session，不是 #455 Web 总索引。研究记录（未提交）：docs/research/EXPERIMENT_CHILD_SESSION_2026-09-09.md。本轮只读源码与 npm 元数据，未 pi install。

复现（父会话激活 intercom → Direct/Workflow child 预检失败）对 @tt-a1i/openpi 0.8.1 / origin/main 0d17f45 成立：inheritedChildToolAllowlist(pi.getActiveTools(), …) 点名父 active 工具，blockedPackageSources() 从 child 摘掉包。当前实验对照工作树 a9b40f0 没有这两套 API，默认 spawn 不投影父工具面，因此默认路径不会预检必挂。

把 intercom 从 requested 清单里丢掉，能停 0.8.1 的挂起，并应保持 #128 的资源隔离。它 不让 child 的 confirm() 到达 parent：child 绑定是 { mode: "print" }，hasUI === false，confirm() 恒为 false。那是「无人可答」，不要记成用户拒绝。pi-intercom 还把 PI_INTERCOM_SESSION_ID 写进共享 process.env；同进程并发 child 会串身份。工具 send 在 !hasUI 时跳过 confirmSend（fail-open）。

parent-forwarded ask 的合同在 #497，通道归 OpenPI。不要用 intercom 当父子权限桥。不新开安装器。