mirror of
https://bitbucket.org/siakitem/my-pi.git
synced 2026-08-28 08:35:57 +00:00
43 lines
3.0 KiB
Markdown
43 lines
3.0 KiB
Markdown
# Migration guide: forwarded asks and the bounded-delegation checkpoint
|
|
|
|
Starting with the release that closes #635, a permission request forwarded up from a subagent carries the **child-fixed access facts** through to the authorizer chain.
|
|
As a side effect, the bounded-delegation checkpoint now applies to forwarded asks the same way it already applied to local ones.
|
|
This is a **breaking change** for one narrow configuration.
|
|
|
|
## Who is affected
|
|
|
|
You are affected only if **all** of the following hold:
|
|
|
|
- You name an authorizer chain link in `authorizerChain`, and
|
|
- that link is **allow-capable** (it can return `allow`, not only `deny` / `defer`), and
|
|
- a subagent forwards an `ask` to your session that was raised by the `path` or `external_directory` gate.
|
|
|
|
If you run no chain link, or run only a deny-first link — including the first-party [`@gotgenes/pi-permission-model-judge`](https://github.com/gotgenes/pi-packages/tree/main/packages/pi-permission-model-judge), which only ever denies or defers — **nothing changes for you**.
|
|
|
|
## What changed
|
|
|
|
The checkpoint downgrades a link's `allow` to `defer` on the excluded surfaces (`path`, `external_directory`), so the request falls through to an interactive prompt instead.
|
|
It selects the surface from the **gate** surface — the surface the matching rule lives on — falling back to the displayed surface when no gate surface is available.
|
|
|
|
A forwarded request previously arrived with no gate surface, so the checkpoint fell back to the child's *display* surface, which is the tool name (`write`, `edit`, `read`).
|
|
A tool name is not an excluded surface, so a link's `allow` on a forwarded `path`-gated request was honored.
|
|
The identical request made directly in the same session was capped, because a local request always carries its gate surface.
|
|
|
|
Forwarding was therefore a way around your own delegation boundary: a link could approve `~/.ssh/config` for a subagent that it could not approve for the main session.
|
|
Now the gate surface crosses the forwarding hop, and both paths behave identically.
|
|
|
|
Unchanged: a forwarded `bash` ask, and a forwarded tool ask gated by a per-tool rule (`write: ask`), are both already on non-excluded surfaces and are not capped.
|
|
`deny` and `defer` verdicts were never capped and still are not.
|
|
|
|
## What you need to do
|
|
|
|
Nothing, unless you run an allow-capable link.
|
|
|
|
If you do, expect an interactive prompt where that link previously auto-approved a forwarded subagent request for a path.
|
|
To keep such a request from prompting, grant it in policy rather than through the link — the `path` and `external_directory` rules in your config are consulted before the chain runs, so an `allow` there resolves the request without reaching an authorizer at all.
|
|
|
|
## Related
|
|
|
|
Issue #620 will replace the whole-`path` exclusion with a narrower secret-shaped one, letting a link allow a non-secret path again while keeping secret-shaped paths capped.
|
|
That refinement applies to local and forwarded asks alike, so the two paths stay aligned.
|