codex create

The codex CLI is proposed, not shipped. This page describes the intended scaffold command. The workbench it configures is shipped through codex-plugin dev.

Usage

npx codex create my-pedal --template fx-react
cd my-pedal
pnpm exec codex-plugin dev --cwd . --project plugin.config.json --open

create takes a directory name and a template. It writes a self-contained workspace: a kernel stub, a parameter schema, a UI that already renders the schema, and a plugin.config.json that already knows how to become a plugin. Nothing is left as a TODO you have to discover later — the project exports a VST3 on the first try, it just does not do anything interesting yet.

Templates

Template	What you get
fx-react	Audio-in → audio-out effect, React UI. Start here for pedals.
fx-vue	Same effect scaffold, Vue UI.
instrument-react	Note-driven instrument with voice allocation wired, React UI.
instrument-vue	Same instrument scaffold, Vue UI.
midi-tool	MIDI in → MIDI out, no audio path. Arps, chord tools, mappers.

The effect and instrument templates differ in two places that matter: the manifest category field (Fx versus Instrument, which is what the DAW reads when it decides where to file your plugin), and whether the kernel stub is handed note events. midi-tool has no audio path at all — its kernel reads and emits AudioEvent values and never touches a sample buffer.

The React and Vue variants are genuinely only a UI swap. The kernel, the schema, and the manifest are byte-identical between fx-react and fx-vue. If your framework is neither, pick either one and replace src/ — the SDK is a module you import, not a framework adapter, so Svelte, Solid, or hand-written DOM all work. See Audio SDK.

Flags

• --template <name> — one of the five above. Required; there is no default, because guessing wrong costs you a rewrite of the kernel signature.
• --name "My Pedal" — the human-readable plugin name written into plugin.config.json. Defaults to a title-cased form of the directory name.
• --vendor "Your Name" — the vendor string the DAW shows. Defaults to a placeholder you should change before you publish.
• --id music.example.my-pedal — the reverse-DNS plugin id. Defaults to one derived from the vendor and directory name. This id is load-bearing: the VST3 class ids are derived deterministically from it, so two plugins sharing an id will collide in a host.
• --pm npm|pnpm|yarn|bun — which package manager to use for the install step and which lockfile to write. Detected from your environment when omitted.
• --no-install — write the files and stop, leaving dependencies to you.

What lands on disk

The scaffold is small enough to read in one sitting. The files you will actually edit are src/kernel.ts (your DSP), src/schema.ts (your parameters), your UI entry point, and plugin.config.json (identity and build wiring). Everything else is build configuration you can ignore until you need it.

Two Vite builds are configured from the start: the normal web build, and a plugin-flavored build whose output directory is named by ui.dist in the manifest. The plugin shell embeds that second bundle as the plugin editor, which is why what you see in the browser and what you see in the DAW are the same bundle rather than two lookalikes. Project structure walks the tree file by file.

Next steps

Run codex dev to get a hot-reloading server with a parameter inspector, then codex export when you want a .vst3. If you would rather start from something that already makes a sound, codex clone forks any published tool into a local project instead of starting from a stub.