codex publish
Submit a tool to the directory: required assets, the review checklist, and versioned updates.
The
codexCLI is proposed and not yet shipped. The command surface below is the intended one; today the equivalent steps run through the workspace scripts andplugin-shell-kit generate.
Usage
npx codex publish
# checking metadata … ok
# checking license … MIT
# building web bundle … ok
# uploading screenshots (2), demo preset (1) … ok
# submitted for review → /tools/my-pedal (pending)
publish reads your plugin.config.json, builds the web bundle, checks the
submission requirements, uploads your assets, and files the tool for review. It
does not upload a binary — the directory builds the downloadable artifacts from
your source so that what people install matches what the playground runs.
The five required things
The CLI refuses politely until it has all five, naming what is missing rather than failing at the end of an upload.
- Metadata — name, a one-line tagline, a category, and tags. The tagline is the line people read in a list of a hundred tools; it earns more editing than it usually gets.
- A license — any OSI license, or a commercial one if you are selling. See Licensing for what the directory accepts.
- At least one screenshot. Your UI is the thing people are choosing between. A screenshot of the actual plugin, not a logo.
- A demo preset, so the browser playground has something good to load on first visit. Default parameter values are almost never the flattering ones.
- A source link if the tool is open. Omit it and the listing says the source is closed, which is a fine choice — it just should not be an accident.
Metadata and license live in your manifest and package metadata; screenshots and presets live in your project. Nothing here is entered into a web form you have to remember to keep in sync with your repo.
Review
Review is a human listening to your tool and checking it does not blow up a speaker or a CPU. Not a taste judgment and not a code audit — the questions are whether it produces dangerous output levels, whether it eats a core doing nothing, and whether the listing describes what the thing actually is.
Usually a day or two. If something comes back, you get the specific reason and
you resubmit with publish again; there is no separate appeals workflow.
What you get when it goes live
Three things, from one submission. A live URL at /tools/your-tool. A browser
playground anyone can hit without an account, running the WASM backend with your
demo preset loaded — this is what turns a link into a try, and it is the single
biggest reason a tool gets used. And a download button for the plugin builds,
signed for the platforms the directory distributes, so your users are not
clicking through a security warning to hear your reverb.
Versioned updates
Publishing again with a bumped version in your manifest ships an update. Old
versions stay resolvable, because a session someone saved six months ago should
still open.
This is where the stable parameter indices from
codex export pay off. Automation lanes are addressed by
index, so as long as you add parameters at the end rather than reordering
existing ones, a project automating your Tone knob in v0.1.0 still automates the
Tone knob in v0.4.0. Reordering or removing a parameter silently repoints
somebody's automation at a different control — the generator can see the change
and will warn, but it cannot fix it for you.
Your plugin id must not change across versions. The VST3 class ids are derived
from it, so a new id reads to a DAW as an entirely different plugin and old
sessions stop finding yours.
Updates go through the same review, usually faster since the reviewer is comparing against something already approved.
Related
Publishing covers the full lifecycle including deprecation
and transfer. Licensing covers what you keep, what changes if
you charge money, and the fact that nothing you build is locked in — every
published tool can be self-hosted. If you want to start from someone else's
published tool rather than a blank template, see
codex clone.