// AGENT MEDIA · CODEX

Codex video generation: a paid command inside a closed sandbox

Codex cannot make video, and adding the ability runs straight into two gates rather than one. Clize supplies the command — clize gen video "a drone pass over a foggy pine ridge" --confirm writes an MP4 to disk for a flat $0.48, whatever length the clip turns out, refunded if the job fails. Codex supplies the other gate: by its own documentation the agent runs with network access turned off by default, and under the standard Auto preset it stops and asks before running anything that needs the network. So the first paid generation involves two deliberate yeses — yours to Codex about reaching the internet, and --confirm to Clize about spending money. That is more friction than a browser tool, and it is the correct amount for a command that costs money every time it runs.

$0.48 a clip, flatApproval + money gateDetach with --asyncNo Google key

What to install, in three lines

Codex reads skills from the shared agent-skills directory, so there is no Codex-side configuration to write:

$ npm i -g @clize/clize
$ clize login
$ clize install --codex     # writes to ~/.agents/skills/, not ~/.codex/skills/

Then either let Codex match the skill from your request, or name it explicitly with /skills or a $ mention before you spend anything. The Codex installation and invocation details are covered in full on the image page; the rest of this one is about what happens when a skill wants to run a command that costs money and touches the network — which, on Codex, is a more interesting question than on any other host.

One thing to rule out first: codex mcp add clize -- clize-mcp is a valid registration and it will not help here. There are no MCP tools for video, image or music generation; those verbs live in the CLI and are reached through the skill. The MCP server covers the other half of the product.

The network is off until you say otherwise

Codex documents its default posture plainly: the agent runs with network access turned off, and locally it uses an OS-enforced sandbox that limits what it can touch, usually to the current workspace, plus an approval policy that decides when it must stop and ask. In the standard Auto preset — spelled out in the docs as --sandbox workspace-write --ask-for-approval on-request — Codex reads, edits and runs commands inside your working directory on its own, and asks before touching anything outside it or reaching the internet.

A video generation is squarely in the ask category. It is an HTTPS call to a hosted API, so the first time your session runs it you will be prompted to allow the escalation. Three consequences that are easy to discover the hard way:

  • Read-only mode will simply refuse. If you have switched the session to read-only with /permissions to plan without side effects, the command cannot run at all — correctly, because it spends money.
  • An unattended run needs a decided policy, not a hopeful one. A scheduled or headless Codex run has nobody to answer the prompt. Decide the sandbox and approval settings for that environment up front rather than finding out at 3am that a batch never started.
  • Codex cloud is a separate calculation. Its agent phase runs offline by default unless internet access is enabled for that environment, so a clip generated from a cloud task requires that switch to be on.

None of this is friction Clize adds; it is the host being careful, and it is the reason this page exists separately from the Claude Code version of the same command, where the surrounding rules are different.

Two gates, and they are not the same gate

It is worth separating them, because they protect against different accidents and people conflate them constantly.

Codex approval policyClize money gate
Question it answersMay this process run and reach the network?May this specific call spend from the balance?
Who enforces itThe host, on your machine, per sessionThe product, server side, per command
How it is satisfiedYou approve the escalation, or you configure the sandboxThe command carries --confirm
Where it does not applyAnother host, another preset, a cloud environmentNowhere — it is the same in every host and in a cron job

The second one is the reason a Clize command is safe to hand to an agent that has already been granted network access. Run it bare and it prices the work and stops:

$ clize gen video "harbour crane at blue hour, slow push-in"
{ "quote": { "model": "veo", "modality": "video", "estUsd": 0.48, "currency": "USD" },
  "message": "📋 Quote about $0.48 (video). Add --confirm to generate." }

There is no allowance to pre-approve and no self-service ceiling to configure — the check is per call, every call, which is blunt and leaves no path where an agent loop drains a balance quietly. Because it lives in the product rather than in a host prompt, it behaves identically in a background run that has nobody to answer a dialog.

Minutes-long work, and a session that will not wait

A clip takes minutes, not seconds. Waiting in the foreground means holding a Codex session open while it does nothing useful, and a session that ends mid-render used to mean losing track of paid work entirely. Clize keeps the job on the server, so detaching is a first-class move:

$ clize gen video "harbour crane at blue hour, slow push-in" --async --confirm
{ "id": "gen_9c1e04a7", "state": "running",
  "message": "Submitted; generating in the background. Fetch the result with clize gen status gen_9c1e04a7." }

That returns straight away, which also keeps the approval story tidy: one short network call to submit, then nothing until you come back for the result. Later — a different session, a different day, a different machine on the same account:

$ clize gen jobs                 # running work listed first
$ clize gen status gen_9c1e04a7  # one poll; if it has finished, the file is written now

The status check is also the download: when the job has completed, that call fetches the bytes and writes the MP4 at that moment. Note where it writes. Codex limits writes to the active workspace by default, so keep --out inside the project directory you launched from — --out ./assets/shot-03.mp4 — and you never trip the second kind of approval prompt. The default location, ./clize-assets/, is already inside the workspace.

What you get for forty-eight cents

One clip, at most eight seconds long, with the model choosing the exact length — the duration flag is documented as ignored on veo and is dropped rather than sent upstream, so nothing you pass will stretch it. Price does not vary with length: $0.48 covers a five-second result and an eight-second result alike, which makes a forecast a matter of counting clips rather than seconds.

Plan the prompt around that ceiling. Eight seconds carries one camera move and one idea; a sequence is several calls, each written as its own shot, joined in whatever editor you already use. To keep a product or a character stable between them, generate a still first and pass it as the opening frame with --from-image; veo accepts up to three reference images in total, counting that first frame, and refuses more before charging. Aspect ratio is honoured as given with --aspect 16:9.

Failed work is credited back automatically — a provider error, a rejected submission, or a job that reports failure while you poll it all refund. A clip that arrives and is merely disappointing does not: it was produced, so it was billed. The video cost calculator turns that into a monthly number if you would rather see it as a budget than as a sentence.

The last gate is you

When the file is written, the message Clize returns with it says the agent cannot watch video or listen to audio, and that the path belongs to a person to judge — not to be concluded on. That is the third gate, and it is the one no configuration can automate away. Codex can write the prompt, get the approval, spend the forty-eight cents, retrieve the file and drop it into the branch it is working on. Somebody still has to watch eight seconds and say yes.

Which is a fair place to end, because it describes the whole shape of the thing. Codex decides whether the command may run. Clize decides whether it may spend. You decide whether the result is any good. Each gate belongs to whoever actually has the information to answer it, and none of the three is doing another’s job. Installing takes about a minute, and the reference marks every command that can spend.

// FAQ

Can Codex generate video?

Not on its own. Installing the Clize skill with clize install --codex adds the command: clize gen video "<prompt>" --confirm submits the job and writes an MP4 into the working directory. No Google Cloud project and no API key of yours is involved, because the hosted path carries the provider credential and your Clize balance pays.

Why does Codex ask for approval before the command runs?

Because generating a clip is a network call, and Codex documents that the agent runs with network access turned off by default. Under the standard Auto preset it works inside your workspace freely and asks before reaching the internet or writing outside it. Approving that escalation is separate from spending: the command still needs --confirm before any money moves.

Will it work in read-only mode or in an unattended run?

Read-only mode refuses it, correctly, since the command spends money. An unattended or scheduled run has nobody to answer an approval prompt, so decide the sandbox and approval configuration for that environment in advance. Codex cloud is separate again: its agent phase is offline unless internet access is enabled for that environment.

How long is a clip, and does length change the price?

At most eight seconds, with the model choosing the exact length — the duration flag is ignored on veo and is dropped rather than forwarded. Price is flat at $0.48 per clip regardless, so a forecast is a count of clips rather than a count of seconds. A longer sequence is several calls joined in your own editor.

The session ended while it was rendering. Do I lose the money?

No. The job lives on the server. Submit with --async to get the id immediately, then from any later session run clize gen jobs to find it and clize gen status <id> to poll once — if it has finished, that call downloads the bytes and writes the file right then. Jobs that genuinely fail are refunded to your balance automatically.

Where should I tell it to save the file?

Inside the project you launched Codex from. Its sandbox limits writes to the active workspace by default, so ./clize-assets/ or an explicit --out ./assets/shot-03.mp4 stays inside the permitted area, while a path elsewhere on the disk will trigger another approval prompt.

clize gen video — submit, detach, come back

Give Codex a camera it has to ask to use.

One install, one approval, one confirmation — then a job that keeps rendering whether or not the session that started it is still alive.

$ npm i -g @clize/clize && clize login
$ clize install --codex
$ clize gen video "harbour crane at blue hour, slow push-in" --async
[ Agent Media → ]