Skip to content

feat(web): expose Pi Trust state and native approval flows #343

New issue
New issue
Open
Open
feat(web): expose Pi Trust state and native approval flows#343

Description

@sowen1023
sowen1023
opened on Sep 2, 2026

Parent

Problem

The Web runtime reuses Pi ProjectTrustStore when opening a workspace, but the browser does not expose the resulting trust/permission state or a native confirmation flow. Users cannot tell why an operation is unavailable, inspect the authority of the active workspace, or safely approve/deny an action without leaving the Web workbench.

This must not be solved with a browser-owned permission database or by silently widening the Session authority.

Value

  • Make the active security boundary visible before tools execute.
  • Allow Web users to handle supported confirmations without bypassing Pi.
  • Preserve one source of truth for Trust, approval, and tool authority.

Approach constraints

  • Pi Trust and confirmation mechanisms remain authoritative.
  • A trust-changing request must bind to the exact canonical workspace and active Session.
  • Only the authenticated controlling browser client may answer a pending confirmation.
  • Confirmation receipts must distinguish approved, denied, expired, stale, and already-settled requests.
  • Snapshot and SSE events must be bounded and must not expose credentials or private confirmation payloads.
  • Do not persist a second browser-specific permission policy.
  • Child and package tool boundaries must remain fail-closed.

Acceptance criteria

  • The Web snapshot reports the active workspace Trust state from Pi-owned state.
  • The UI clearly displays trusted, untrusted, restricted, and unknown states that Pi can distinguish.
  • Unsupported operations explain the relevant Trust/permission boundary instead of failing silently.
  • Supported pending confirmations can be inspected and approved or denied through the native confirmation seam.
  • Stale, cross-workspace, cross-Session, and non-controller responses are rejected.
  • Refresh/reconnect restores the canonical pending/settled state without replaying an approval.
  • No Web action can grant authority beyond the Pi Session or package policy.
  • Tests cover untrusted workspaces, approval, denial, expiry, stale receipts, reconnect, and shutdown.
  • Documentation and setup status describe the Web Trust surface.
  • bun run check and bun run test pass.

Out of scope

  • Remote/public authentication.
  • A second ACL system.
  • Automatic project trust.

Activity

  1. testikun commented on Sep 4, 2026

    @testikun
    testikun
    on Sep 4, 2026
    Collaborator

    I am taking a focused read-only Trust-boundary diagnostics slice. I will expose the exact canonical workspace, whether trust-gated project resources exist, Pi ProjectTrustStore decision state, and a derived trusted/untrusted/restricted/unknown status through an authenticated endpoint. This is distinct from #360 compact snapshot trust state and does not add a browser permission database or any trust-changing action. No UI changes are planned, so a real-browser screenshot is not applicable to this slice.

  2. tt-a1i
    added a parent issue on Sep 7, 2026

  3. tt-a1i commented on Sep 8, 2026

    @tt-a1i
    tt-a1i
    on Sep 8, 2026
    Collaborator

    补充一个可以直接纳入本 Issue 验收的实际任务场景：Web 无法回应删除预存文件所需的 native confirmation，工具却反复提示获取用户确认。

    检查日期：2026-09-08；OpenPI 固定源码：ed9dbc1018f890fd54375f5371990ddfee8af5df。

    触发路径：

    1. 工作区有预存的 obsolete.txt；用户要求删除这个文件。
    2. 模型调用在 guard 支持语法内的 rm obsolete.txt。
    3. cleanup extension 直接调用 ctx.ui.confirm，没有先识别无 UI 状态。
    4. Web 将 extensions 绑定为 print 且不传 uiContext；Pi 0.85.1 固定源码的 no-op confirm 直接返回 false。
    5. guard 阻止执行，提示 obtain explicit user confirmation to delete it，但浏览器没有对应的待确认请求和答复入口。

    用户在下一条聊天输入“确认删除”不等同于回答这个 native confirmation；相同命令再次进入 no-op confirm，仍会失败。不应让模型换一种删除方法来绕过保护。

    已经执行实际 createWorkspaceCleanupGuard 的隔离准入探针，目标只是 /tmp 下预存的测试文件：

    第一次 rm obsolete.txt + confirm:false -> block
第二次 rm obsolete.txt + confirm:false -> block
对照组同命令 + confirm:true             -> allow
文件仍然存在；没有执行任何 rm 或其他删除命令

    这证明实际 guard 在 no-op confirmation 下的判定；没有运行真实 Pi Session、浏览器或模型。它是阻断用户任务的可用性问题，不是权限绕过或文件丢失，也不能将 false 描述成“用户主动拒绝”。

    建议优先覆盖这个明确的小闭环，保持本 Issue 已有的 Session、工作区和 controller 绑定要求：

    • 展示 exact deletion 的原生待确认请求，用户可以批准或拒绝，答复有明确回执。
    • 批准仅作用于原请求和准确路径；过期、重复、跨 Session 或跨工作区答复不能放行。
    • 不支持交互时明确返回 unavailable 和可执行的人工处理指引，而不是继续要求一个无法提供的确认。
    • Web 普通聊天中的“同意”不会自行变成某个 pending native request 的批准。
    • 确认前文件保持不变；真实拒绝和 UI 不可用在模型反馈及浏览器显示中可区分。

    无需扩大为第二套权限系统；复用 Pi 的确认边界并让它在 Web 中可见、可回应即可。

  4. tt-a1i commented on Sep 8, 2026

    @tt-a1i
    tt-a1i
    on Sep 8, 2026
    Collaborator

    补一组社区实现证据，便于把本 Issue 收敛为原生扩展 UI 桥，而不是对每个扩展重写审批逻辑。

    @jmfederico/pi-web 在固定提交 182c5ade390fc4c31189f44f0daf518817c74e71 已实现：

    OpenPI 可在现有 Pi bindExtensions seam 提供这样的 Web UIContext adapter，沿用 Pi Trust 和各扩展的权限判断。回复绑定 Session/runtime epoch/request identity；刷新恢复 pending 投影；重复、过期和错误 Session 的答复不得授权。真实 cleanup confirm、原生 select/input 测试扩展，加上取消/断连/会话切换，是具体的首批验收。

    这不等于任意扩展自定义界面都已适配。OpenPI 的 ask_user 使用 ui.custom，需要独立的 Web 呈现/答复方案或明确的不支持反馈，不能仅凭 confirm/select/input 桥宣布 setup 问答已经打通。

    研究只读源码，未安装/运行第三方包，不宣称运行兼容认证；本项目 MIT，当前 peer 为 >=0.84.0 <0.85.0 || >=0.85.1。仅借鉴此 adapter，不引入其独立 daemon、多机器配置或整套插件系统。

    研究记录：Pi 社区能力研究与候选清单（2026-09-08）。源码证据、运行验证与采用决策分别记录。

  5. tt-a1i commented on Sep 9, 2026

    @tt-a1i
    tt-a1i
    on Sep 9, 2026
    Collaborator

    结论

    #343 后半（native approval）仍空着；前半（Trust 状态）在 origin/main 0d17f45 已有只读诊断，不要和「浏览器改 Trust」或「#497 政策 ask」合成一张卡。

    本轮只读源码，未 pi install、未跑 Web Host / TUI /trust。对照：Pi 6160683 / 0.85.1；官方 project-trust.ts blob 6234bc24；OpenPI 本工作树 a9b40f0 无 web/。

    新的源码事实（相对本 Issue 已有评论）

    已有评论钉过 cleanup-guard 的 print confirm()===false，以及 @jmfederico/pi-web 的 confirm/select/input 桥。下面几条当时没写：

    1. Trust 对话框的绘制者是 Pi，不是官方 example，也不是 OpenPI。 resolveProjectTrusted（packages/coding-agent/src/core/project-trust.ts）顺序：override → 无 trust-requiring 资源 → project_trust 事件（第一个 yes/no 压掉内建提示）→ trust.json → defaultProjectTrust → 无 UI 则 false。Native 有两套 UI：启动 showStartupSelector，以及之后 /trust 的 TrustSelectorComponent（写盘后要求 Restart）。
    2. 官方 project-trust.ts 只演示事件。 拷进 ~/.pi/agent/extensions 或 -e 之后，扩展变成绘制者。OpenPI 不要 Wrap，Web 不要复刻它的五选项。
    3. Web Host 不走完整解析器。 createRuntime 用 !hasTrustRequiringProjectResources(cwd) || trustStore.get(cwd) === true，然后 bindExtensions({ mode: "print" })。不发射 project_trust，不读 defaultProjectTrust。因此 defaultProjectTrust: "always" 在 Native 会信任、在 Web 仍可能 restricted；session-only Trust 也不会进 store。
    4. 只读投影已落地，不是审批。 GET /api/trust + projectWebTrustStatus + InspectionPanel（feat(web): integrate contributor session provenance and trust diagnostics #442 / feat(web): inspect runtime state and restore archived conversations #445；feat(web): expose project trust diagnostics #392 / feat(web): project Pi trust state in snapshots #360 已关）。测试锁住「改 store ≠ 立刻改 Session 权威」。i18n 已写 Manage trust through Pi。feat(web): expose Pi Trust state and native approval flows #343 验收里的 pending confirmation 仍无。

    脏仓 / confirm-destructive 是会话 before_* 门，不是 Trust。已在同日 docs/research/EXPERIMENT_HANDOFF_GATES_2026-09-09.md 覆盖（#193 / #472），不要并进本 Issue。

    建议（研究，不是 Decision）

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

  6. testikun commented on Sep 17, 2026

    @testikun
    testikun
    on Sep 17, 2026
    Collaborator

    我想认领 #343 尚未实现的 Web 原生确认闭环（与已完成的只读 Trust 诊断分开），请维护者确认是否有并行工作。计划复用 Pi 扩展 UI 的 confirm 边界，先以 cleanup guard 的预存文件删除为验收场景；pending/答复绑定 canonical workspace、Session、runtime epoch、request id 和控制者，覆盖批准、拒绝、超时/取消、重复/过期答复与重连。普通聊天中的“同意”不能代替原生答复；无 UI 时要明确 unavailable，不新增浏览器权限数据库或扩大 Pi authority。实现前会核对最新 main 和关联 PR，完成后按模板给出测试及真实浏览器证据；本切片不宣称关闭整个 Issue。

  7. testikun commented on Sep 17, 2026

    @testikun
    testikun
    on Sep 17, 2026
    Collaborator

    技术方案（本切片，尚未实现）：

    1. 继续使用已落地的 Pi-owned Trust 只读投影；不做浏览器修改 Trust。预存文件删除只由现有 cleanup guard 的路径/来源判定提出确认，普通聊天不会结算它。
    2. Web Host 为发起 prompt 的浏览器标签绑定独立、不可从共享 SSE/快照读取的控制者凭据；pending 包含 canonical workspace、Session、turn epoch、commandId、随机 requestId、准确路径和 deadline。浏览器刷新可恢复同一控制者的 pending 查询，其他标签即使持有共享 Host bearer 也不能答复。
    3. 确认内容仅通过控制者鉴权的单独读取接口获取；SSE 只发不含路径/私有 payload 的失效通知。答复先验证控制者、工作区、Session、turn、requestId、deadline，再原子 settle 一次；回执区分 approved/denied/expired/stale/already-settled。AbortSignal、turn settled、切 Session、Host stop 均 fail closed 并清理 Promise/timer。
    4. 接到 cleanup guard 的 Pi confirm 判定处，显式区分浏览器确认不可用与用户真实拒绝。TUI 保留当前 ctx.ui.confirm，不创建浏览器持久权限库；测试覆盖 exact rm 路径、无 UI、过期/重放/跨控制者/跨 Session、断线及关机，另做真实浏览器证据。

    实现前的兼容性发现：Pi 0.85.1 的 bindExtensions({uiContext}) 会让全部扩展 ctx.hasUI 变为 true，单独提供 confirm 会误启用 ask_user、sessions、workflows 等 TUI-only custom UI。不会盲目绑定半套 UIContext；先验证可以复用的 Pi seam 和非 TUI 行为，必要时将 Web transport 限定在 cleanup guard 的确认调用，不把该局部桥误称为通用 select/input/custom 支持。此评论是设计提案，不是验收结果。

  8. testikun commented on Sep 17, 2026

    @testikun
    testikun
    on Sep 17, 2026
    Collaborator

    Web 预存文件删除的控制者绑定确认切片已提交 PR #549：#549 。准确路径仅通过原 prompt 控制者鉴权的 pending 读取接口交付；批准、拒绝、过期、重复、跨工作区/Session/轮次与关机均有 fail-closed 回执/测试。原生 Pi TUI confirm 不变，未把局部 cleanup transport 宣称为通用扩展 UI 或浏览器 Trust 改写。完整 Node/Vitest 通过，Chrome 新用例通过；完整 Chrome 有一次 #347 已修的导航焦点竞态，隔离复跑通过，详见 PR Validation。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions