Whole-repo reasoning
Codex plans and edits across the entire repo. A Primo site is the repo — pages, blocks, content, config — so there’s nothing it can’t reach.
Primo + Codex
Build and edit a website with Codex.
Pull your whole site down as files, point Codex at the repo, and let it edit anything — components, content, pages, routes — the way it would any codebase. Push it back, and your client edits the same files live in the browser. No data layer to instrument, no API between the code and the content.
Codex edits the site. Your client edits the same site.
Codex is at its best with a repo it can reason over end to end — files it can read, plan against, and edit across. Primo gives it exactly that: primo pull brings your entire site down as plain files. Blocks are Svelte components, content and config are YAML. Codex edits them like any other repo, in the terminal or wherever you run it.
When you primo push, those files sync to a relational database on the server, and your client edits the same site visually — on the rendered page, in the fields each block declared. The editor generates itself from each block's fields.yaml; there's no glue code to write to make a field editable.
That's the difference from a git-backed headless CMS. With Tina, your files get indexed into a GraphQL data layer and you instrument each field with useTina before it's editable. Primo has neither the data layer nor the per-field wiring — the editor and the renderer read the same files and rows directly.
Why Codex fits Primo
Just files, no API
No GraphQL layer, no useTina wiring, no SDK to call. Components are .svelte, schema is fields.yaml, content is YAML. Codex edits files.
Client edits the same source
After push, your client edits on the rendered page in the fields your blocks declared — the same source Codex just edited. One source of truth.
The loop with Codex
Four steps. The CLI is the real Primo CLI — primo pull, primo push. What’s Codex-specific is step three, where you hand the task to Codex.
Pull the site as files.
Brings your whole site into the repo — Svelte blocks, YAML content and config, pages, routes. Auth is a PRIMO_TOKEN you generate per site in the admin.
$ primo pull <your-site-host>
✓ pulled 14 blocks · 6 pages · content + config
Run the local preview.
Starts the local dev server. It watches the repo and auto-imports your file changes so you see them as Codex edits.
$ primo dev
▸ dev server on http://localhost:5173 · watching files
Let Codex edit anything.
Hand Codex the repo and describe the change. It plans and edits across the whole codebase — components, content, new pages — no fields to instrument first.
$ codex "redesign the pricing page and add a /vs/storyblok comparison"
✎ editing blocks/pricing · creating pages/vs/storyblok.yaml
Push it back, hand off the browser.
Only changed files upload. They sync to the database on the server, and your client edits the same site live — on the page, in the fields your blocks declared.
$ primo push
✓ pushed 3 changed files · live
MIT · open source. The CLI is the same one your editors authenticate with — no separate API surface to learn. The same loop works from Claude Code and Cursor.
Questions
Can I use Codex as a CMS?
Yes. With Primo, Codex edits your whole site as files in a repo — components, content, schema, and routes — then primo push syncs it to a server where non-technical clients edit the same source visually. There’s no separate admin or API between Codex and the content.
How does Codex edit a Primo site?
You run primo pull <your-site-host> to bring the site down as files, then point Codex at that repo. Blocks are Svelte components and content is YAML, so Codex edits them like any codebase. primo dev previews changes locally; primo push deploys them.
How is this different from TinaCMS with Codex?
Tina indexes your files into a GraphQL data layer and you instrument each field with useTina before it’s editable. Primo has neither — the editor generates itself from each block’s fields.yaml, and the editor and renderer read the same files and database rows directly. Less for the agent to wire up, and nothing between the code and the content. See the full Primo vs Tina breakdown.
Do my clients need Codex to edit the site?
No. Codex is how you build and change the site as code. After you push, your client edits on the rendered page in the browser — click and type — with no editor and no agent involved.
How does Codex authenticate to push?
The CLI reads a PRIMO_TOKEN from your environment, which you generate per site in the admin. primo pull <host> clones the project and primo push uploads only changed files. It’s the same auth an editor uses — no separate API.
Build it with Codex. Hand it to a human.
One command to spin up a workspace. Point Codex at the repo, then hand your client the browser.
$ npx primo-cli init my-workspace
✓ workspace ready · server.yaml written
MIT · open source · free forever