Approval
Every submission and every update is reviewed by a human against the rules on this page. Most are checked mechanically; the judgement calls — originality, honesty, quality — are exactly why users trust the catalogue enough to install things into their own cloud. And if these rules aren't for you: you can always distribute your poppy outside the catalogue, sideloaded from disk, forever, with no revenue share to us.
| Rule | What it means |
|---|---|
| Open repository | Your listing links a public repo containing the poppy's source. No open repo, no listing — it's how packages are verified and how users audit you. |
| It has a face | A square PNG icon, legible at small sizes, and original — imitating another poppy's mark (or AgentsPoppy's) is grounds for delisting. |
| The name ends in “Poppy” | Your brand + the suffix. Unique in the catalogue; first listed keeps the name. |
| Verified packages | Releases ship the byte-reproducible zip from pack-extension, pinned by sha256 and verified on every machine before install. |
| Confined from the user's files | A poppy with a backend must declare "runtime": "node22", "isolation": "strict": the host then runs it under Node's permission model — it can read its own install folder and write only its own data folder and the OS temp directory, and it cannot start child processes. The user's home directory (their AWS credentials included) is off-limits by the runtime. An unconfined backend is rejected. The one exception is a declared, one-release data migration whose confined successor is already named. Keep state in bootstrap.dataDir; hand files to the user through the one-shot download route; receive files through the frontend picker. |
| Declares where it connects | Two declarations, both in permissionSet.network. egress — where the code you deploy connects ("none", "aws-only", or named hosts): required on every poppy, no exceptions — a manifest without it is refused, new listing and update alike (declare "none" if you deploy no cloud code; that is one honest line and it reads in your favour). machine — where your own frontend and backend connect on the user's machine: optional, and the one the host actually enforces. Declare it and AgentsPoppy checks every connection your backend opens against it before your code loads, and serves your tab a matching Content-Security-Policy; undeclared destinations are refused. Declare nothing and the host observes and logs instead — but your permission screen can then never say “Host-enforced”. Loopback and the AgentsPoppy API your Feedback tab calls are never counted against you. |
| No bundled runtimes | Your package ships your code, not a runtime. A compiled-in Node (SEA) or an embedded service binary (Redis, Postgres…) is rejected automatically — you declare what you need and the platform provides it. |
| An accepted license | Open source, from the accepted list — see licensing. |
| The Feedback tab | Your last tab is “Feedback”, rendered by the platform's own <agentspoppy-feedback> element — rate, request a feature, report a bug, support the developer. You don't build it: declare host:openExternal, set bugsUrl to your public issue tracker, and mount the element. A poppy without it isn't listed. It's also where the star rating on your listing comes from. |
| An age rating | A short content questionnaire at submission computes Everyone / 13+ / 18+; the reviewer can adjust it. |
| A data-flow declaration | Whether any data leaves the user's cloud, what, where, and why — see Data & privacy. |
Competing poppies are welcome. Copies are not. You may absolutely build a poppy that competes with an existing one — but it must introduce functionality that genuinely distinguishes it, not re-skin or re-upload someone else's work. We will not host ten poppies that look alike and do exactly the same thing: it clutters the catalogue for users and it punishes the developers who did the original work. Copy-pasting another poppy's code and submitting it — with or without cosmetic changes — is rejected outright, and repeat attempts close the account.
Cloud work survives navigation and can resume. Destroying anything takes a real two-step confirmation. Errors speak plain language. And every button responds — a pending state on click, no dead controls. This is the single most common reason for a “needs changes.”
Least-privilege permissions that rate green or
amber with “No risks to other resources identified”,
and a passing npm run certify — provably leaves no trace.
A real, working poppy in genuine use — names can't be reserved with placeholder apps. Abandoned placeholders are delisted (with notice) and the name is freed.
The catalogue is one of two doors. The other — sideloading from disk — needs no approval, no listing, and no license blessing from us. Your users install directly from your repo at their own judgement. The catalogue buys you reach and the trust that comes with review; it never locks you in.