Background
Pi's own docs (`usage.md:308`) confirm it "intentionally does not include ... permission popups." Claude Code has a real soft-enforcement tier baked into the host: a risky tool call pauses and asks the user to approve/deny before running. Pi has no equivalent UI primitive at all.
This matters more than the other Pi omissions (plan mode, to-dos) because it's a whole enforcement tier, not a UX convenience. Today, ca-pi's enforcement on Pi is binary: a stored governed wrapper either hard-blocks a command (H-03/H-05/H-20/etc.) or it doesn't run at all — there's no "pause and ask the user" middle ground the way there is on Claude Code, because Pi exposes no permission-prompt API for extensions to hook into.
Decision so far
Leaning toward building our own solution rather than waiting on/relying on Pi adding native permission popups upstream — gives us control over the exact confirm UX and keeps ca-pi's governance model consistent across hosts instead of depending on an upstream feature we don't control the shape of.
Open questions to work out during design
- What primitive does Pi's extension API actually expose that a soft-confirm layer could be built on top of (`ctx.ui.confirm`? a custom registered tool with an interactive dialog? intercepting before the wrapper hard-blocks and offering a confirm step first)?
- Where does hard-block (H-03 style) still make sense vs. where a softer confirm-then-proceed flow is more appropriate — not every governed action should become "ask first," some should stay non-negotiable.
- How does this interact with the trust model (Pi's own project-trust gate) — is a confirm-popup redundant with trust, or does it serve a different moment (per-action vs. per-project)?
No implementation yet — this issue is to track the decision and design work.
Background
Pi's own docs (`usage.md:308`) confirm it "intentionally does not include ... permission popups." Claude Code has a real soft-enforcement tier baked into the host: a risky tool call pauses and asks the user to approve/deny before running. Pi has no equivalent UI primitive at all.
This matters more than the other Pi omissions (plan mode, to-dos) because it's a whole enforcement tier, not a UX convenience. Today, ca-pi's enforcement on Pi is binary: a stored governed wrapper either hard-blocks a command (H-03/H-05/H-20/etc.) or it doesn't run at all — there's no "pause and ask the user" middle ground the way there is on Claude Code, because Pi exposes no permission-prompt API for extensions to hook into.
Decision so far
Leaning toward building our own solution rather than waiting on/relying on Pi adding native permission popups upstream — gives us control over the exact confirm UX and keeps ca-pi's governance model consistent across hosts instead of depending on an upstream feature we don't control the shape of.
Open questions to work out during design
No implementation yet — this issue is to track the decision and design work.