clize-cli

# Clize

**Clize is a CLI and MCP server that gives AI coding agents real-world actions: domains, email, deploys, payments, and media generation.** Your agent already has a brain — Clize gives it hands: a domain, a working inbox, a live website. One CLI (plus an MCP server) so coding agents in Claude Code / Codex can register domains, run real email, build & ship sites and short clips, generate media, and collect payments from their customers — across as many projects as you run.

→ **[clize.ai](https://clize.ai)**

## Install

```bash
npm i -g @clize/clize
clize install          # wire clize into your coding agent (Claude Code / Codex)
```

`clize install` is the step that makes your agent actually *reach for* clize — a binary on your `PATH` doesn't tell the agent it exists. By default it drops clize's skill (when to use it + the safety gates) into each agent's skills dir; the skill is lightweight — only its short description sits in context until something triggers it. It auto-detects Claude Code (`~/.claude`), Codex (`~/.codex`) and Pi (`~/.pi`); Codex and Pi share the open `~/.agents/skills` directory, so any agent that reads it gets the skill too. Scope with `--claude` / `--codex` / `--pi`, preview with `--dry-run`. Add `--mcp` to also register the `clize-mcp` server — opt-in, because an MCP server's tool list stays in context every session.

Update later with one command — pulls the latest release and refreshes the skill together:

```bash
clize update            # or `clize update --check` to only check for a newer version
```

If something looks stale after an update, `clize doctor` prints what's installed vs what's actually running — CLI version (and the upgrade command that works for your install manager: volta / pnpm / asdf / …), skill drift, and control-plane reachability.

Output is English by default. `CLIZE_LANG=zh` (or a `zh*` system locale) switches the CLI, the MCP tool descriptions and the control plane's messages to Chinese; the dictionary lives in `src/i18n/zh.ts`.

## Quickstart (hosted)

Log in and go — your agent never touches Cloudflare:

```bash
clize login                              # browser authorize; the first login creates your account
clize claim acme --email                 # free identity: acme.clize.app + support@acme.clize.app
clize init --handle acme                 # bind this directory (deploy / send / inbox infer the rest)
clize email inbox --wait-for "verify"    # give the new inbox a minute, then the agent signs up with support@acme.clize.app and reads the code here
clize status                             # who is waiting (real people + codes only), this month's spend
clize email send --to a@b.com --subject "Re: …" --text "…"   # queued for a one-tap approval in the console; --confirm sends now
clize deploy ./site                      # ship a static site → https://acme.clize.app
```

## Examples you can run (recorded 2026-10-01, with timings, costs and what failed)

| Example | What it does | Cost |
| --- | --- | --- |
| [01 · first verification email](examples/01-first-verification-email/) | install → claim an address with an inbox → read a verification code → queue a reply a person must approve | $0 |
| [02 · HTML → HTTPS → your domain](examples/02-html-to-https-site/) | a three-file folder to `https://<slug>.clize.app`, then a domain and a mailbox on it | $0 (+ the domain, quoted first) |
| [03 · one SEO loop](examples/03-seo-check-loop/) | `clize seo check` on a real site → two changes tied to numbers → publish → dated re-read | $0 |

Each one is Clize's own account and site (self-use), not a customer story.

## Hosted — just log in

| Log in with | What runs where |
|---|---|
| `clize login` (web: GitHub / Google / email) — or `clize login --token clize_…` for CI / headless | Commands call the clize backend; resources run on clize's infra. You never touch Cloudflare / Vercel keys. |

clize is a **thin client**: the CLI / MCP carry no infrastructure credentials and talk only to the clize control plane — domains, email, deploy, and media all run hosted. (Credentials live in your dashboard; bring-your-own Cloudflare / Vercel is configured there, not on your machine.)

A few specifics worth knowing:

- `clize deploy <dir>` and `clize email send` need `--domain` / `--from` — unless the directory is bound with `clize init --handle <slug>`, which infers both from `./clize.json`. Deploy is directory-based (multi-file static sites).
- `gen image --ref/--mask` (image-to-image / inpainting / multi-image composition) work hosted — reference-image caps follow the upstream model: 16 for `gpt-image-2`, 14 for `nano-banana-2` (video/`veo` takes 3); each ≤10 MB, ≤80 MB total. `gpt-image-2` runs as an async task (heavy multi-ref jobs take minutes — no sync-pipe timeouts): the CLI waits by default (`--timeout`, default 300 s), or use `--async` and collect with `gen status <id>`; one image per task (`--n` > 1 → split), `--mask` inpainting is `nano-banana-2` only. `gen budget` pre-approval isn't hosted yet: every generation confirms individually with `--confirm`.
- Free `*.clize.app` handle: `clize claim <slug>`. Your own domain: `clize domain buy` / `clize domain import`. Run `clize check` to verify your login.
- Free-tier quotas (anti-abuse, per tenant): 3 handles · 5 mailboxes · 10 claim attempts/day · 30 outbound emails/day · 20 deploys/day · 500 MB per site. Any top-up lifts you to the trusted tier (10 · 30 · 30 · 200 · 100 · 5 GB). Over-limit calls return a plain 429 — nothing is charged.
- A deploy target is a free handle or a whole domain in your account; a subdomain of your domain (`blog.example.com`) is not a separate deploy target today. Names bought with `clize domain buy` are registered with Clize's registrant contact at the underlying registrar — to be the registrant of record, register elsewhere and `clize domain import`. Some ccTLDs (`.de .fr .es .jp .kr .com.br .uk .eu`) are not registrable through Clize; `clize domain tlds` lists the 555 that are.

## What it does

| Area | Commands |
|---|---|
| **Identity** | `clize claim <slug> --email` — a first-come, free identity for your agent: `<slug>.clize.app` (site placeholder) plus a receiving `support@<slug>.clize.app`. Without `--email` you get the name and the site only (`clize email setup <handle>` opens the inbox later) — inbound is opt-in because each inbox costs 4 DNS records in the shared `clize.app` zone, and that zone is the whole platform's free-handle capacity |
| **Domains** | `clize domain search / tlds / buy / import / list`; `clize domain check <domain>` runs six layers in repair order — registry delegation (public DoH) → Cloudflare zone → worker binding → content → **edge AI-crawler policy** (Cloudflare `ai_bots_protection`; new zones default to blocking AI crawlers from 2026-09-15, and a blocked edge beats any robots.txt) → **http→https** (a real `http://` request must get a 301 to https; clize turns on Cloudflare's Always Use HTTPS on every zone it deploys to, imports or registers, and `domain canonicalize` does too) |
| **Email** | The mailbox your agent signs up for services with and reads verification codes from (`clize email inbox [domain] --wait-for <text>` polls until the mail arrives), and the inbox real people write to. `clize email address add <addr>` opens a mailbox in one step (object + receiving) on any domain you own — as many per domain as you need (`ops@`, `sales@`, one per agent or per person); `--forward me@gmail.com` copies mail to a personal inbox, `--owner <member>` makes it someone's private mailbox. `support@<slug>.clize.app` is available on any claimed handle via `clize email setup <handle>` (or `clize claim <slug> --email`). Read with `inbox` (triaged: promos / notices / spam are filtered, `--all` shows everything) / `show` / `thread` / `search`, correct triage with `mark`, send with `send` (`--attach`). Mail is stored permanently and indexed. **Multi-user**: `clize members invite alice@corp.com --mailbox alice@<domain>` lets a person log in and use their own mailbox; owners/admins see every mailbox in the account. **Per-agent keys**: `clize email key create --scope read,send --address ops@<domain>`. Command reference: [clize.ai/docs/commands](https://clize.ai/docs/commands/). |
| **Outbox** | Interactive `clize email send` without `--confirm` lands in an outbox instead of vanishing as a draft: a person approves or rejects it in the console (Home → needs you → Inbox), or from the digest email's signed one-tap link; `clize email pending` lists what is waiting and `status` counts it. A **standing allowlist** (a recipient or `@domain`, weekly cap 5) can be set only in the console — approvals and the allowlist are refused to CLI-issued keys, so a prompt injection cannot grant itself an exemption. Sends to allowlisted recipients within the cap go out without `--confirm`. |
| **Send API** (server-callable) | `POST /v1/email/send` — transactional email from a long-running backend (fly.io / cron), Resend/Postmark-shaped, sending from a domain already in Clize (no second email vendor). Auth is a **scoped send key** (`clize_sk_…`: send-only, lockable to specific domains) — `clize email key create/list/revoke`. No `--confirm` (the human-review gate stays on interactive `email send`). Idempotency-Key, HMAC-signed delivery webhooks (bounce/complaint), RFC 8058 one-click unsubscribe + suppression lists (`email delivery-webhook / suppressions / messages`). Walkthrough: [sending from a backend with a scoped key](https://clize.ai/inbox/replit/) · [webhooks and delivery events](https://clize.ai/inbox/inbound-email-webhook/). |
| **Media** | `clize gen image / video / music` — text→image (`gpt-image-2` / `nano-banana-2`, with `--ref` / `--mask` for image-to-image and inpainting), text/image→video (`veo`), text→music (`suno`); long tasks via `gen jobs / status`. Every spend is gated by `--confirm` (`gen budget` pre-approval for hosted is on the roadmap). Results land as local files, ready to `d