To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.
name: pi-agent
description: pi is a minimal terminal coding agent harness. This snap packages the published Linux binary release. As ‘pi’ is already taken in the snapstore, the snap is named ‘pi-agent’
The pi coding agent is a CLI coding agent similar in scope to claude or copilot. Its focus is on extensibility, it is meant to interface with arbitrary binaries as well as read/write arbitrary files and sockets. For instance, in the course of normal operation pi resp. the LLM backend might need to launch and inspect lxc containers, connect to ext. APIs, create and run Python scripts, inspect sysfs paths, as well as run common tools such as git, uv, bash, …
Preserving this operational breadth would be impossible within strict confinement.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
A key step in the classic granting process is Publisher Vetting. To successfully vet a publisher, we need to verify their connection to the upstream. Since you’re not currently part of the upstream, could you clarify whether the upstream is willing to adopt the snap, or if they are open to having you, as the snap publisher, join the upstream (if you’re willing to do so) (#askForInfo)?
Whilst the technical reasons are clear, I don’t think agents fit into any of the supported categories for classic confinement. This topic requires further discussion with the snapd architects to clarify whether agents can be added to the supported categories, or whether certain agents may be subject to an override granted on a case-by-case basis.
Policy changes like this can take quite a while, there are many parts involved in the decision making process, especially for changes to the classic confinement requirements (and it might end up differently than expected (i.e. a new ai-agent interface might come out of it not permitting classic at all)), you’ll have to be patient…
We are leaning toward granting ‘classic’ status for such snaps. One area I’m less comfortable is granting it to individual accounts for software like this. Depending on your appetite, Peter, might I suggest working with @zyga to transfer to rthe ubuntu-snaps namespace, or perhaps contribute to Snapcrafters.
Feels like a better move to me to have these under either Verified Publisher or Star Developer accounts, given the level of trust implied by classic confinement.
Another option is to see if the upstream have interest - in which case we can help them get Verified Publisher status, and get it published under their name, which is probably the best case!
I can coordinate (I’m on sick leave but I’ll respond to pings when I feel better) and help with packaging. I’d love to build a small ecosystem of classic snaps that have similar packaging and similar maintainance like opencode, and that over time can grow snap-specific features and relationship to our inference snap collection.