The Anticode CLI: work on a project from your terminal
The Anticode CLI is a single Node script with no dependencies. It signs in without ever seeing your password, pulls a project into a folder as an editable spec and the page as it ships, pushes your edits back with a guard against overwriting newer work, and publishes. Publishing from the terminal runs the same server-side security gate as the builder.
Seven commands
| Command | What it does |
|---|---|
anticode login | Signs in with a code you approve in the browser and stores a token on this machine |
anticode logout | Revokes this machine's token on the server and removes it locally |
anticode whoami | Shows the account you're signed in as and what's left of your model builds |
anticode projects | Lists your projects with their id, name, kind and design system |
anticode pull <project> [dir] | Writes the project into a folder: anticode.json, spec.json and index.html |
anticode push [dir] | Uploads your spec.json changes and rebuilds index.html |
anticode publish [dir] [--slug NAME] | Pushes, then publishes at the address you give |
It needs Node 20 or later and nothing else. A project can be named by its id or by its name; if two projects share a name, the CLI lists both ids and asks you to use one.
Signing in with a device code
A website builder CLI that asks for your password in a terminal is a liability: the password ends up in shell history, scripts and screenshots. Anticode's uses a device-code flow instead, the same pattern TVs and game consoles use to sign in.
anticode loginasks the server for a device code and prints an address and a short code in the formABCD-EFGH. The alphabet leaves out 0, O, 1, I and L, so a code read off a terminal is hard to mistype.- It opens your browser at that address, but only if the address is on the Anticode server you're signing in to.
- You approve the code while signed in to Anticode in the browser, where your password, magic link or two-factor sign-in already lives.
- The CLI receives a personal access token once and saves it in your config folder with owner-only permissions. The code expires after ten minutes if nobody approves it.
On the server the token is stored only as a hash. It works for projects, sites and builds, and nothing else: account settings, your password and billing all need a browser session, so a leaked token can't delete your account. You can revoke it from the dashboard's CLI access settings, or with anticode logout. The CLI will only talk to an API over HTTPS, apart from localhost during development.
Pull, edit, push
anticode pull creates a folder named after the project with three files. spec.json is the build spec you edit: the name, kind, design system, copy, sections and features. index.html is the page exactly as it would ship, rendered by downloading Anticode's own design engine from the server and running it locally, so what you open in a browser matches what the builder publishes, CMS sections included. anticode.json records which project and which version the folder holds.
Edit spec.json in any editor and run anticode push. The CLI renders the page again, then sends the spec with the version you pulled. If the project changed in Anticode since then, the server refuses, and the CLI tells you to save your spec somewhere, pull again and re-apply your edits. Nothing is overwritten. Pushes like this never use model builds. If the builder is open, it redraws with your change and offers an undo; see code-to-canvas sync.
Publishing still goes through the gate
anticode publish pushes first, then asks the server to publish at the slug you pass (3 to 40 letters, numbers or dashes), or the one the folder used last time. The server re-runs its security checks on the exact HTML, and the design gate and security baseline apply as they do in the builder. If something fails, nothing goes live and the CLI prints each failed check with its detail, so you can fix spec.json and try again. On success it prints the live address. A terminal is not a way around the checks; it's another way to reach them.
Limits
- It edits; it doesn't build. There's no command to start a model build or to ask for a change in words. Use the builder or an assistant connected over MCP for that.
- Spec size.
spec.jsonis capped at 32 KB. - No layout preview server.
index.htmlis a static file you open yourself; there's no watch mode. - Your email must be confirmed before the server will publish anything, from the CLI or anywhere else.
For the full file format behind the spec, see anticode.json. For a walk-through from first login to a published change, see the guide to editing a website locally with the CLI.
Questions people ask
Does the CLI ever see my password?
No. You approve a short code in the browser, where you're already signed in, and the CLI receives a token. It never asks for or handles your password.
Where is the token kept?
In a config.json in your user config folder (AppData on Windows, Application Support on macOS, ~/.config on Linux), readable only by your user. Never commit it.
What if I edited the site in the builder after pulling?
Your push is refused with a version conflict. Pull again, re-apply your edit to the new spec.json, and push.
Can a teammate's CLI publish into our Team workspace?
A member of a Team workspace can publish its projects, and the site belongs to the workspace owner, on the owner's plan. The same gates apply.