This risk is most relevant for users who run Pi in repositories they have not reviewed or do not trust. Pi's security guidance requires users to trust the codebases they work with, or to use an external sandbox or isolation boundary for untrusted repositories.
Affected versions
Affected: < 0.79.0
Patched: 0.79.0
The solution
Pi 0.79.0 added project trust gating for project-local inputs. On interactive startup, Pi now asks before loading project-local settings, instructions, resources, package-managed resources, or extensions when a trust decision has not already been saved for the working directory.
Non-interactive modes do not prompt. Without a saved trust decision, they ignore project-local inputs unless --approve or -a is passed. Users can also pass --no-approve or -na to ignore project-local inputs for a single run even when a project is already trusted.
Before trust is resolved, Pi loads only user/global extensions and extensions passed explicitly on the command line. Those extensions can participate in the project_trust event; project-local extensions are not loaded until after the project is trusted.
Recommendations
Upgrade @earendil-works/pi-coding-agent to version 0.79.0 or later.
After upgrading, review project trust prompts carefully and only trust repositories whose Pi-specific configuration and extensions you are willing to run. The upgrade makes this trust decision explicit, but it does not change Pi's security model: users should work only in trusted repositories, or use external isolation for untrusted code. Use --no-approve for one-off runs where project-local inputs should be ignored. For untrusted repositories or unattended automation, follow Pi's security guidance and run Pi inside an operating-system sandbox, container, VM, or other isolation boundary with only the files and credentials required for the task.
Workarounds
Before and after this change, Pi users should only run Pi in repositories they trust, or in an external sandbox or isolation boundary when working with untrusted code. Pi 0.79.0 adds an explicit trust prompt as a defense-in-depth and user-safety improvement; it is not a sandbox and it does not make untrusted repositories safe.
If upgrading is not possible and your workflow already enforces this trust boundary, continue to avoid running Pi directly in untrusted repositories. Inspect and remove project-local Pi configuration and resources before use, especially project-local extensions and package configuration. Disabling extensions and other project resources with command-line flags can reduce exposure, but trusted or isolated execution remains the primary mitigation.
Timeline
2026-05-25: Report received.
2026-06-05: Project trust gating committed.
2026-06-08: Project trust refinements and security model documentation completed.