runtime: 试点全局 allow/ask/deny，不引入社区权限包依赖

[tt-a1i]

结论

在 OpenPI 内试点全局 allow / ask / deny，学习 @gotgenes/pi-permission-system 的 most-restrictive-wins、symlink-canonical path、fail-closed bash parse、以及「不受信任项目不能放宽 global」。不把该社区包做成依赖，不 merge 其代码。 先解决 in-process child 的 ask 转发与 authority 顺序。OpenPI 当前只有 workspace-cleanup-guard，没有统一权限门。

不新增第二条配置命令；权限策略走 /openpi-setup。Pi 继续拥有 install / update / uninstall。本轮未安装、未运行该包。

事实

冻结身份（last-seen 2026-09-08）：

包	版本 / 日期	来源
@gotgenes/pi-permission-system	npm 31.1.2（2026-09-07）	https://www.npmjs.com/package/@gotgenes/pi-permission-system · https://github.com/gotgenes/pi-packages/tree/main/packages/pi-permission-system

公开 README 声明的机制（未在本轮执行验证）：

• 规则同时匹配引用路径与 symlink-resolved canonical path；
• path → external_directory → per-tool → bash 采用 most-restrictive-wins；
• 无法解析的 Bash 与内部 gate error 不静默放行；
• 不受信任项目不能用 project config 放宽 global policy。

官方对照缝（example，不是社区产品）：permission-gate、protected-paths、sandbox、gondolin。见 Pi examples README。

OpenPI 对照：extensions/workspace-cleanup-guard/（阻止删除工作区已有路径）；child 边界在 CHILD_EXCLUDED_TOOL_NAMES / CHILD_SAFE_PACKAGE_TOOL_NAMES。未分类工具必须 fail-closed。

2026-08-09 审计已把权限系统列为「试点、不依赖」：docs/design/PI_COMMUNITY_PACKAGE_AUDIT_2026-08-09.md。本 Issue 推进该方向，不改写那份结论。

推断

直接 pi install 该包有三类风险：child 的 ask 无 UI / 无正确 parent identity；permission policy 与 OpenPI child allowlist / Trust 的 authority 顺序不清楚；/openpi-setup 之外出现第二套配置与批准语义。因此试点必须在 OpenPI 进程内实现最小门，而不是加载第三方 extension。

不引入 @gotgenes/pi-permission-model-judge。模型裁决不能成为权限根。

建议

1. 设计 allow/ask/deny，覆盖 tools / bash / MCP / paths，most-restrictive-wins。
2. child session 的 ask 转发到唯一 parent UI；不能在 child 里静默放宽。
3. 任何新模型可见工具必须写入 CHILD_EXCLUDED_TOOL_NAMES 或 CHILD_SAFE_PACKAGE_TOOL_NAMES；未分类 = 不可见 / 拒绝。
4. 对照官方 example，不对照「再装一个权限产品」。
5. OS 级隔离（sandbox / gondolin）是另一件事，见后续 Ideas 讨论，不要和本 Issue 的 policy 门 混成一个 PR。

未知

• 当前 @earendil-works/pi-coding-agent 的 permission-gate 与 OpenPI in-process child 的实际组合行为（本轮未跑）。
• 社区包对 OpenPI child Resource Loader 的真实加载范围（本轮未安装）。

验收

• 设计 allow/ask/deny 覆盖 tools / bash / MCP / paths，most-restrictive-wins
• child session ask 转发到 parent，不能在 child 里静默放宽
• 不新增第二条配置命令；走 /openpi-setup
• 不 merge 社区包；对照官方 permission-gate / protected-paths / sandbox / gondolin examples
• 未分类工具 fail-closed（含 factory-registered tools）
• 不引入 model-judge 作为权限根

关联

• AGENTS.md runtime invariants（权限、Trust、fail-closed、child 不扩权）
• 2026-08-09 社区包审计（权限候选）
• capabilities: 定义 Browser、Web、GitHub、Computer 与 Security 的外部 Provider Seam #169（seam ≠ 自研 Security 产品）
• Capability Discovery and Authority：Explicit Intent 还是 Model-Driven Adaptive？ #312（Capability Discovery and Authority）
• OpenPI 产品哲学：Build for Model Leverage #299 / Capability Shape and Harness Value：什么时候该用 Primitive、Skill、Subagent 或 Workflow？ #314（机制 vs 工作流；不要变成第二套 OS）
• 研究记录（本 checkout，未提交）：docs/research/PI_COMMUNITY_PLUGIN_SURVEY_2026-09-08.md

[tt-a1i]

2026-09-08 目录第二轮：执行门的兄弟包仍挂在本 Issue，不要和出站脱敏混写。

• @aliou/pi-guardrails npm 0.17.1：文件保护 / 工作区外路径 / 危险 shell 确认（学策略，不依赖）
• cc-safety-net npm 2.3.4：hook 拦破坏性命令和 secret 文件访问
• pi-verdict npm 0.7.0 与 pi-auto-approval：模型分类器批准确认。仍然不引入 model-judge 作为权限根（与 @gotgenes/pi-permission-model-judge 同一拒绝）

工具结果发给模型之前的 secret egress filter 是另一条轴 → #507。本轮未安装、未运行。配置继续只走 /openpi-setup。

[tt-a1i]

结论

源码对照确认：OpenPI 必须在进程内自建最小 allow/ask/deny，不能 pi install @gotgenes/pi-permission-system。Direct/Workflow child 走 createChildResources → createAgentSession → bindChildSessionExtensions({ mode: "print" })，hasUI === false 且 confirm() 恒为 false。OpenPI 不发射 subagents:child:session-created，也不设 PI_SUBAGENT_PARENT_SESSION，所以社区包的 selectAuthorizer 会落到 DenyingAuthorizer（confirmationUnavailable），不是唯一 parent TUI。官方 permission-gate 在 !hasUI 时同样 block，但没有 parent identity。OS sandbox / gondolin 仍是 #502，不是本门。

本轮只读源码与 npm 元数据，未安装、未运行社区包，未改用户 Pi 配置。

新证据（相对 Issue 正文）

• 社区包 npm 现为 31.1.3（正文仍写 31.1.2）。只读 clone：gotgenes/pi-packages af980a236fd3ff043e3d432336b0f3de540fdd1b；earendil-works/pi 6160683a4a8012f0d1cd30c145df18b4ca6f5176（in-tree @earendil-works/pi-coding-agent 0.85.1）。OpenPI 对照 a9b40f0。
• 「project 不能放宽 global」在社区包里只约束 untrusted；trusted 后是 last-match overlay，可以放宽某一 pattern。OpenPI 试点应改成跨 scope 最严交集。
• emitToolCall 无 try/catch（user_bash 有）。社区包用 createFailClosedToolCall 把抛错变成 block。workspace-cleanup-guard 的 confirm 抛错会漏出去。
• 社区包默认无匹配是 ask，不是 allow；gate 内部错误是 block，不是 ask。

研究记录（本 checkout，未提交）：docs/research/EXPERIMENT_PERMISSION_SYSTEM_2026-09-09.md

不改 08-09 审计结论。不引入 model-judge。不新增第二条配置命令。不把 isolation 失败静默退回共享工作区。

[tt-a1i]

结论

学 @pify/yolo 的 unwrap / 不透明命令 / blind-write；忽略自动批准梯度和可选 model classifier。不要 pi install 该包。

事实（源码，未安装未运行）

yolo 0.9.1（pifydev/yolo@4c019d0）：

• unwrapCommand 只增加待检查字符串（bash -c、sudo、xargs、find -exec、管道/链的每一侧）。读不出 payload（eval、-c "$VAR"、base64 | sh）标 opaque → ask，不能向下取整为 allow。
• 本会话从未 read 就 write 已存在文件、或 read 之后 mtime/size 变了，在 approve/strict 询问。无 UI deny。
• /yolo 梯度与 classifier（只能 allow→ask）是自动批准产品。本 Issue 已拒绝 model-judge 做权限根。

OpenPI a9b40f0 workspace-cleanup-guard：手写 splitter 能剥一层 bash -c，并算出 opaqueDestructiveCommand，但 index.ts 只看 kind === "block"，allow 时丢掉 opaque 旗。读不出 rm 目标 → 放行。file-mutation-display 只换 TUI，不存 pre-image，不是门。

建议

试点 allow/ask/deny 时，「读不出 payload」必须是 ask/deny，不是 allow。blind/stale write 是可选的只读知识门，不是 undo。pre-image / rewind 走 #508 / #154，不要并进本门。

本地深读：docs/research/EXPERIMENT_HANDOFF_GATES_2026-09-09.md。未 pi install、未运行。

[tt-a1i]

结论

workspace-cleanup-guard 的 opaque 位是 两棵树的事实，不要从「#172 已关」推出「动态 rm 仍可绕过」。本轮只读源码与测试，未改 guard，未 pi install，未运行。

新证据（相对本帖已有的 yolo / print-mode 评论）

• 本工作区 a9b40f0（package.json 0.4.0，committer 2026-08-26 02:15 UTC，早于 fix(workspace-cleanup-guard): block opaque rm targets #201 merge）：inspectShell() 会立 opaqueDestructiveCommand，before() 原样带回，index.ts 只看 kind === "block"。测试 ambiguous shell deletion is not misrepresented as protected 焊死 allow + opaque === true。write 从不 opaque；edit 不进这个扩展。
• #172 被 PR #201（5fe0450，2026-08-26T13:30:35Z）关掉，不是「关了但绕过还在」。#433 / PR #436 是那次收紧之后的 storm 假阳性，已修。
• origin/main 0d17f45 / npm 0.8.1：同一份 index.ts blob（6492cf3）。差在 workspace-provenance.ts（本树 1376c86 vs origin 6c76ee3）：opaque 在 before() 内变成 unverifiedCleanup() block，不再出现 allow+opaque。
• Child print-mode 的「碰巧 fail-closed」只覆盖 能列出 protectedPaths 的字面量删除（confirm() === false）。本树上 opaque bash parent/child 一样放行——那条路径不调 confirm。origin 上 opaque 两边都硬拒，仍然没有 parent 转发，也不是 user_denied。

建议（仍是本 Issue 的讨论，不是新实现票）

• 不要在 a9b40f0 上另写一版「if (opaque) block」。本树测试写的是 fail-open；workspace-cleanup-guard: 动态 rm target 可绕过已有文件删除确认 #172 评论已说明直接 block 全部 opaque rm 会误伤 quote/escape、brace/tilde、以及 echo rm。最小 fail-closed 已经在 fix(workspace-cleanup-guard): block opaque rm targets #201 落地。
• 不要重开 workspace-cleanup-guard: 动态 rm target 可绕过已有文件删除确认 #172。本帖继续只做全局 allow/ask/deny 的 不透明地板（任意工具 / 包装器 / 不可解析 bash → 有 UI 则 ask，无人可答则 deny），与 cleanup-guard 共存。不要把 origin 的「改用 literal rm」文案当成三态合同。
• 学 yolo 的「读不出不能向下取整为 allow」，不学自动批准，不学 user-rule 放宽。

本地记录（本 checkout，未提交）：docs/research/EXPERIMENT_CLEANUP_GUARD_2026-09-09.md

[tt-a1i]

2026-09-09 社区安全反模式目录：本试点 不要抄 的三条对照（未安装、未运行）。不改「进程内自建 allow/ask/deny、不依赖社区权限包」的方向。

1. 模型裁决当权限根。 @gotgenes/pi-permission-model-judge 2.0.0 自己是 deny/defer-only、opt-in chain link，从不 allow。那不能改写成「让模型决定一次 tool_call」。pi-verdict / pi-auto-approval 仍是同一拒绝类（09-08 已写）。试点不要 authorizerChain。
2. prompt 不是 bash 门。 @plannotator/pi-extension 0.27.12 文件头与 README 写 planning 阶段 Bash unrestricted — prompt-guided；tool_call 只拦 write/edit 的 markdown 路径。OpenPI 已有机械 allowlist（Plan Mode 设计调研：Codex / Claude Code / OpenCode 对比与我们的结论 #27 / bash-policy.ts）。不要为了 Plan UX 把门改回说明文字。
3. isolation fail-open 不并进本 PR。 @quintinshaw/pi-dynamic-workflows 3.10.1 仍把 worktree 写成 best-effort、失败后共享 cwd。那是 worktree 合同（见 EXPERIMENT_WORKTREE_ISOLATION_2026-09-09.md），不是 runtime: 试点全局 allow/ask/deny，不引入社区权限包依赖 #497 的 tool_call 门。

目录全文：docs/research/EXPERIMENT_SECURITY_ANTIPATTERNS_2026-09-09.md（本地 draft）。另有配置自动落盘、安装默认 telemetry、stealth browser、MITM 代理 —— 分别挂 #498 / #505 / #169 / #474，不进本 Issue 实现面。

[tt-a1i]

Visibility 过滤器 ≠ 本试点的 Policy 门

不改本 Issue 方向：进程内自建 allow/ask/deny，不依赖社区权限包。

后续研究（未提交）：docs/research/EXPERIMENT_THIRD_PARTY_CHILD_FILTER_2026-09-09.md。第三方默认不进 child 的家在 #169，不在本票。

gotgenes 的两层仍然对：

1. Visibility（child-session）：未分类 owner 默认不 load 进 Direct/Workflow child。今天只对本包 + pi-intercom 特例成立；用户自装的 mcp/dap/eval/browser 会进 child。这不是本试点该维护的社区名录。
2. Policy（本 Issue）：对 已经可见 的 tool_call 做 allow/ask/deny；child ask 转发到唯一 parent UI；confirm() === false ≠ user_denied。

两层相加，不要合成「权限+防火墙」巨 PR。不要把 "mcp" / "dap" 写进 CHILD_EXCLUDED_TOOL_NAMES（双向守卫要求该名已被本包注册）。本轮未实现、未 pi install、未开新 Ideas。