Codex image generation: install the verb, not an API client

Why this is confusing in Codex specifically

OpenAI ships an image model. Codex is an OpenAI product. So the reasonable assumption is that asking Codex for a picture should work, and it does not — Codex is a coding agent with a shell and a sandbox, not an image client. When you search the phrase, the official results you get back are the Images API reference, and that is an answer to a different question: it tells you how to write a program that makes pictures, once you have a key, a billing account and somewhere to put the request.

The rest of the page is forum threads and gists of people wiring exactly that up. Which is fine work, and also the thing you were hoping to skip. Clize is the skip: a CLI that already holds the provider credential, plus a skill that teaches Codex when to reach for it. The interesting part on this host is not the image command — it is identical everywhere — but where the skill goes and how Codex finds it, which is genuinely different from every other agent.

The skill goes to ~/.agents/skills, not ~/.codex/skills

This trips people up, so it is worth being precise. Codex reads skills from the open agent-skills standard directory, and the user-level location is $HOME/.agents/skills. It is not under the Codex home directory, and nothing in ~/.codex/ needs editing. One command puts them there:

$ npm i -g @clize/clize
$ clize login
$ clize install --codex

Check first if you prefer to see before you write:

$ clize install --dry-run --codex

▸ Codex
    skill · up to date · clize → ~/.agents/skills/clize/SKILL.md
    skill · up to date · clize-seo → ~/.agents/skills/clize-seo/SKILL.md
    skill · up to date · clize-site-build → ~/.agents/skills/clize-site-build/SKILL.md
    skill · up to date · clize-site-debug → ~/.agents/skills/clize-site-debug/SKILL.md
    mcp   · skipped (default; add --mcp for the structured tool layer)

Because that directory is a shared standard rather than a Codex private folder, one install serves several agents at once — the same files are read by Pi and by OpenClaw. Claude Code is the exception: it keeps its own personal skills folder, so the Claude Code page shows a different set of paths for the same command. Codex detects skill changes on its own; if a fresh skill does not show up, restarting Codex is the documented fix.

Getting Codex to actually use it

Two routes, and both are worth knowing because they fail differently.

Implicit. Codex loads each installed skill’s name and description up front and picks one when your request matches. Ask it to make a hero image for the landing page it is building and it should reach for the clize skill by itself. The catch is budgetary: that opening list is capped at a small share of the context window — roughly two per cent, or eight thousand characters when the window size is unknown — and when many skills are installed Codex shortens descriptions first and may omit some entirely, with a warning. A machine with thirty skills on it is a machine where implicit matching gets less reliable, through no fault of any one skill.

Explicit, which is why the second route matters. In the Codex CLI, /skills lists what is available and typing $ lets you mention one directly in the prompt. If you are about to spend money on a generation, naming the skill is the cheaper habit — it removes a guess from the loop.

The skill is also what keeps the tool list out of the context window every session. It is a document Codex reads when it decides the task matches, rather than a permanent block of tool schemas. On a host that is already rationing the skills list, that difference is not academic.

codex mcp add is the wrong lever for this job

Codex has first-class MCP support and the registration syntax is its own — a separator before the stdio command, with configuration landing in ~/.codex/config.toml:

# Codex
$ codex mcp add clize -- clize-mcp

# Claude Code, for comparison — same shape
$ claude mcp add clize -- clize-mcp

# OpenClaw, which is not the same shape
$ openclaw mcp add clize --command clize-mcp

You can run that, and for parts of Clize it is genuinely useful. It will not get you a picture. Image, video and music generation have no MCP tools at all — the server exposes mail, domains, DNS, deploys, payments, the storefront and the account calls, and none of the media verbs. That is a real product boundary, not an oversight in this paragraph, and it is stated plainly here because the results page around this query is thick with directory listings promising an "image generation MCP".

So the decision is simple. For pictures, install the skill and let Codex call the CLI. If you also want structured tools for the rest of the surface, register the MCP server as well — clize install --codex --mcp does both in one go — and nothing about how images are made changes. One more detail worth having: Codex stores that MCP configuration in a file shared by the ChatGPT desktop app, the Codex CLI and the IDE extension, so registering once covers all three surfaces.

The command itself, and what it costs

With the skill in place, the loop is short:

$ clize gen image "a matte black kettle on raw concrete, soft window light" --out ./hero.png
{ "quote": { "model": "gpt-image-2", "modality": "image", "estUsd": 0.05, "currency": "USD" },
  "message": "📋 Quote about $0.05 (image). Add --confirm to generate." }

$ clize gen image "a matte black kettle on raw concrete, soft window light" --out ./hero.png --confirm

The bare call quotes and stops; --confirm is what spends. Every image model is the same $0.05, a failed generation is refunded to your balance, and reference images passed with --ref add nothing to the bill — the price is computed from the number of images requested and nothing else. The default model is gpt-image-2, which produces one image per job; ask for several at once and it tells you to run several jobs or switch to nano-banana-2, before charging anything. The reference-image and inpainting rules are laid out in full on the Claude Code page and are identical here.

Where the file lands matters more on Codex than elsewhere. The bytes are written to disk — ./clize-assets/ by default, or wherever --out points — and only metadata comes back through stdout. Codex’s sandbox limits writes to the active workspace by default, so keeping --out inside the project you launched it from is the frictionless choice; a path outside the workspace is the kind of thing it will stop and ask you about.

The repo-scoped copy, and the trap that comes with it

Codex does not only read the user directory. It also scans .agents/skills inside the repository you launched it in, walking up to the repository root, so teams can check skills into a project. That is a good feature and it has one sharp edge: if two skills share a name, Codex does not merge them — both appear.

Which means: do not commit a copy of the clize skill into a project that also has it installed at user level. You end up with two documents describing the same money-spending commands, they can drift apart across a version bump, and which one the agent reads is not something you want deciding whether a generation is gated. Install once at user level, upgrade with clize update, and let every repository on the machine read the same file.

The one legitimate reason to check a copy in is a repository whose contributors should get the tooling without being asked to install anything — a template, a workshop, a shared build environment. In that case, keep the user-level copy off those machines rather than running both.

Video and music from the same install

Installing once gives Codex all three modalities. They are not variations on one command: a clip is a minutes-long job with an eight-second ceiling and a per-clip price, and a track is something nobody in the loop can skim.

• Video from Codex — where the sandbox and the approval policy start to matter, because a paid generation is also a network call.
• Music, on the Claude Code page — $0.12 an MP3 and an honest answer about controlling its length; the commands are the same on Codex.
• Agent Media as a product line — the money gate, the output contract and the model list in one place.

If you are weighing the two hosts rather than the capability, the comparison page covers the wider differences; for media specifically, the only thing that changes is where the skill file lives and how you call it.

$ npm i -g @clize/clize && clize login
$ clize install --codex
$ clize gen image "a matte black kettle on raw concrete" --out ./hero.png