Add a codex-cli image provider: no-API-key generation via the signed-in Codex CLI

[fancy-agent]

Fixes #4128

Why

I'm scratching my own itch: I run Open Design with Claude Code as the chat
agent, and I have a ChatGPT subscription with a signed-in Codex CLI — but no
OPENAI_API_KEY. Today that combination can't generate an image at all.

The only no-key image path that exists is PR #622's
renderCodexImagegenOverride, and it only fires when the chat agent is
Codex. Drive OD with Claude Code / Gemini / Cursor and you're back to needing
a provider API key, even though the machine already has a perfectly good,
already-authenticated image generator sitting in the Codex CLI.

This adds a local codex-cli provider so any agent can generate images through
the operator's own Codex login — no OPENAI_API_KEY, billed to their ChatGPT
subscription.

What users will see

• A new image model codex-image-gen (provider "Codex CLI") in the model
  picker, alongside gpt-image-2, dall-e-3, etc.
• Selecting it generates images with no API key — it drives the local,
  signed-in Codex CLI's built-in image_gen tool.
• It does not add a Settings → Media card and needs no stored credentials
  (same treatment as the hyperframes local renderer).
• The default image model is unchanged (gpt-image-2); codex-image-gen is
  strictly opt-in via the picker.
• If the Codex CLI isn't signed in to ChatGPT (or is pointed at a third-party
  relay where image_gen isn't mounted), generation fails with a clear,
  actionable error instead of a blank/placeholder image.

Surface area

• UI — a new model appears in the New Project / model picker (no new
  page or dialog; it flows from the apps/web/src/media/models.ts registry)
• Keyboard shortcut
• CLI / env var
• API / contract
• Extension point
• i18n keys
• New top-level dependency
• Default behavior change
• None

Screenshots

Entry point — New project → Media → Image → "Model". The new
codex-image-gen model appears under a Codex CLI group marked
Configured (no key needed) and is selectable as the image model:

Filtering the picker confirms it resolves with no credentials required:

Bug fix verification

• Not a bug fix — this is a feature. (New failure-path tests are included
  anyway: see apps/daemon/tests/media-codex-cli.test.ts.)

Validation

Run under Node 24 / pnpm 10.33.2:

• pnpm guard → pass (54/54)
• pnpm typecheck → pass (all workspaces, including @open-design/web)
• node scripts/verify-media-models.mjs → OK (TS + JS registries match)
• pnpm --filter @open-design/daemon test → the new
  media-codex-cli.test.ts (5 cases) passes: success returns the real image
  bytes; the four failure branches (image_gen unavailable, clean-exit-but-no-
  file, non-PNG output, non-zero exit) all throw instead of falling back to a
  stub. Tests use a fake Codex CLI injected via CODEX_BIN — zero tokens.
• Real generation (manual, live daemon, no OPENAI_API_KEY set):
  od media generate --project … --surface image --model codex-image-gen --prompt "a cozy reading nook with a cat, warm flat illustration" produced a
  real 2.58 MB PNG in the project. The artifact came back as
  providerId: "codex-cli", usedStubFallback: false, providerError: null,
  providerNote: "codex-cli/image_gen · 1:1 · 2579406 bytes · ChatGPT subscription (no API key)". Same path exercised through generateMedia
  directly with the real Codex CLI (independent file/sips confirmed a
  1254×1254 PNG). The image_gen smoke (orange-cat) under both workspace-write
  and the default config showed the built-in tool path with no
  scripts/image_gen.py / API-key fallback.

Notes / scope

• The model picker has a per-surface provider allowlist in
  NewProjectPanel.tsx (supportedModels); codex-cli had to be added to the
  image set or the model stays hidden in the UI even though the daemon
  dispatches it — exactly how hyperframes is allowlisted for video. There's
  a regression test for this in apps/web/tests/components/NewProjectPanel.test.ts.
• What I did not drive: a fully autonomous chat run where Claude Code (as
  the chat agent) decides to generate an image. The provider spawns its own
  Codex process and is decoupled from the chat agent, and od media generate --model codex-image-gen (the exact call any agent runtime makes) is verified
  end-to-end above — so agent-independence holds by construction — but I didn't
  script a full Claude-Code-in-the-loop session.
• First version is t2i only — no i2i / inpaint / reference image yet.
• Sandbox: uses the daemon's existing codex policy (workspace-write + network
  on macOS/Linux; danger-full-access only on Windows/WSL via the existing
  codexNeedsDangerFullAccessSandbox() helper). Verified image_gen works
  under workspace-write.
• Not verified on Windows.
• image_gen leaves no distinct event in codex exec --json, so success is
  confirmed from ground truth (exit 0 + the file exists at the path we handed
  codex + a PNG signature), and failures throw — no silent stub fallback (same
  policy as hyperframes).

[Siri-Ray]

@fancy-agent thanks for putting this together. I reviewed the daemon provider wiring, the model registries, and the picker visibility test path. I found one launch-environment issue worth tightening before this ships broadly, but I’m leaving it as non-blocking because it depends on how the daemon was launched and how Codex is installed.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[Siri-Ray]

@fancy-agent thanks for the follow-up here. I reviewed the current daemon provider wiring, the model registries, and the New Project picker change that keeps codex-image-gen explicit opt-in. The picker/default behavior looks covered; I still see one launch-environment issue in the daemon path that is worth tightening, but I’m keeping it non-blocking because it depends on desktop/packaged launch conditions and Codex install shape.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[Siri-Ray]

@fancy-agent thanks for the quick follow-up here. I verified the launcher-path fix on the current head, reviewed the daemon provider and picker changes again, and ran the focused daemon/web suites plus the media registry verifier. I found one remaining config-parity issue worth tightening, but I’m keeping it non-blocking because it only affects deployments that explicitly disable Codex plugins.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[fancy-agent]

Follow-up in f5422f3: the codex-cli image provider now fails fast on a non-subscription login before spawning a turn, and splits runtime failures into actionable classes.

Previously auth problems only surfaced after a full (multi-minute) codex exec turn — an API-key or third-party-gateway login burned the whole turn just to land on a vague "no image" error. The new codex-image-auth.ts reads $CODEX_HOME/auth.json + config.toml up front and classifies the login the same way Codex's own resolved_mode does (OAuth tokens first, then OPENAI_API_KEY; schema taken from codex-rs/login AuthDotJson + the lowercase AuthMode serde). API-key / programmatic / third-party model_provider / not-signed-in each fail fast with specific "switch to a ChatGPT-plan login" guidance.

A non-zero codex exit is also split into auth / quota / transient — a ChatGPT usage-limit (the image_gen tool shares your plan quota, ~5h reset) now reads differently from a network blip; transient keeps the original wording.

Verified: daemon tsc clean, vitest 29/29 (two auth.json fixtures + fail-fast/quota integration tests, RED-checked against a reverted wiring), pnpm guard 54/54, and my real ~/.codex ChatGPT subscription classifies ok (no false-block of a legitimate user).

[Siri-Ray]

@fancy-agent thanks for the quick follow-up on the auth classification path. I reviewed the current daemon provider/auth gate, model registry sync, and New Project picker behavior. The new fail-fast auth handling and opt-in picker behavior look on track; I’m leaving one non-blocking config-parity issue because this media-specific Codex spawn still bypasses the existing global plugin-disable knob.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[Siri-Ray]

@fancy-agent thanks for the thoughtful follow-through on this provider. I reviewed the changed daemon image-provider path, the Codex auth/failure classification, launcher argument parity, the media model registries, and the New Project picker behavior. The current head addresses the earlier launcher and plugin-disable parity concerns, keeps codex-image-gen opt-in rather than a silent default, and has focused coverage for the main success/failure paths. I also ran the media registry verifier successfully; the focused Vitest commands could not run in this reviewer worktree because node_modules/vitest is not installed here. Nice work getting the no-API-key path wired through cleanly.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}