upstream-relation: I stepped up as official maintainer for the snap package, you can see the discussion here. The intention is to merge the recipe upstream as it gets traction.
supported-category: IDEs, orchestration agents/software for running workloads on systems without traditional users where the systems are otherwise managed outside of the agent
reasoning: goose must execute arbitrary host-installed developer tools and project scripts. Available strict interfaces provide only scoped file, socket, or process access; none permits general execution of host binaries. Classic confinement is therefore required.
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.
Actually I wasn’t sure on which category to pick, let’s say what goose does it’s equivalent of what you’d do with opencode or codex for example. It spawns, runs and orchestrates unsupervised (sub)agents to perform actions independently from the user.
I am not sure if goose actually fits into one of the supported categories, and this is a strict requirement for approving classic confinement. In addition, classic confinement is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that goose doesn’t meet these criteria because of the following reasons:
The project seems to be very fresh, according to the upstream repository.
The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.).
I could not find evidences that the project has a strong enough user base currently.
If you need further assistance, feel free to reach out!
It’s right that goose is a very young project and doesn’t have much traction at the moment, but it’s maintained by the AAIF, which is part of the Linux Foundation, and maintains also the MCP and AGENTS.md standards.
We also use the goose agent for the Context Aware Desktop project, and as it’s used internally in one of our products, we do review it, and we should be safe in security terms. For clarity, as the agent is vendored we wouldn’t need a separate snap for the CAD project, but I’m mostly using the goose.desktop for testing components and sometimes generating draft code or docs.
Maybe the IDEs category is the nearest fit, for sure it matches some antigravity and opencode features.
The main question now is how we can vet the publisher in this case. @gabelluardo could you please clarify if you already got push permissions to the upstream project?
I don’t have push permissions to upstream yet, since we agreed to start to publish in a different repo and then merge upstream (and ask for a transfer to them) as the recipe became stable. I understood this is what we usually do with third parties.
Sorry if I somehow set the wrong expectations. From the @reviewers point of view, we are now waiting for the snap to be published under the Ubuntu account before granting classic confinement.
Transfer requests are handled by the @store folks, so you may need to open a separate request for that: transfer-ownership - snapcraft.io. I’m not sure whether there are any additional requirements for the transfer to be done.
