codex-imagegen-mcp
Generates images using OpenAI's image generation through the official Codex CLI and your ChatGPT plan (or, optionally, the OpenAI Images API backend with a gpt-image-2 model); accepts a prompt plus optional base/reference images and an output path, and returns the resulting image's format and dimensions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@codex-imagegen-mcpgenerate a minimalist mountain logo and save it as logo.png"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
codex-imagegen-mcp
A local MCP server that gives Claude Code (or any MCP client) a generate_image tool backed by the official Codex CLI and your ChatGPT plan. No API key, no separate billing: each image counts against your plan's Codex limits.
It also ships a Claude Code skill that teaches the agent to use the tool well for any kind of image, without imposing a style: setup checks, how base and reference images behave, how to write the prompt, and optional multi-step workflows (finish a rough base, remove elements, isolate elements on a flat background).
Claude Code → generate_image (this MCP, stdio) → backend
├─ codex (default) codex exec + your ChatGPT login
└─ openai-api (off) OpenAI Images API, billed separatelyUnofficial. Not affiliated with or endorsed by OpenAI or Anthropic. The
codexbackend relies on Codex behavior that is not documented as a public interface (the$imagegentool insidecodex execand thegenerated_images/<thread_id>/folder). Tested with Codex CLI 0.164.0; a future Codex release may break it.
How it works
The server runs
codex execas a subprocess, with a read-only sandbox, a throwaway working folder and your images attached with--image.Codex reuses the login saved by
codex login. This server never reads or copies tokens orauth.json.The image is found in
$CODEX_HOME/generated_images/<thread_id>/(the thread id comes from the JSON events). Codex's text reply is not used for the path, because it is unreliable.The file is copied to
output_path; the result reports format, real size and warnings.
Related MCP server: codex-image
Requirements
Python 3.11+ and uv
Node.js and the Codex CLI:
npm install -g @openai/codexA ChatGPT plan that includes Codex
Install
Nothing here installs Codex or logs in for you: the skill is only instructions and uv sync only installs the Python dependencies. Steps 1–3 are yours to do once.
Install the Codex CLI:
npm install -g @openai/codexLog in with your ChatGPT account (it opens a browser page where you confirm a code):
codex login --device-authCheck both:
codex --version codex login statusYou should see a version (tested with
codex-cli 0.164.0) andLogged in using ChatGPT. If you logged in with an API key instead, generations are billed on the API, not on your plan.codex login statusreadsCODEX_HOME: run it with the sameCODEX_HOMEyou will give the server, or it may sayNot logged ineven though you are.Clone and install:
git clone https://github.com/vitorvls/codex-imagegen-mcp cd codex-imagegen-mcp uv syncRegister it in Claude Code (user scope, so it stays out of your repos):
claude mcp add codex-imagegen --scope user -e CODEX_HOME=/home/you/.codex -- uv --directory /path/to/codex-imagegen-mcp run codex-imagegen-mcpThe MCP client passes only a minimal environment to the server, so any variable you need must go in the registration with
-e. WithoutCODEX_HOME, Codex can't find your login and answers 401 (the default is~/.codex, so you can skip it if that is where you logged in).(Optional) Install the skill:
cp -r skills/codex-imagegen ~/.claude/skills/
Configuration
Variable | Default | |
|
| Where Codex keeps its login and generated images |
| current directory | Base folder for relative paths |
| system temp | Where each run's logs go ( |
| — | Folders the server must never write to, separated by |
|
|
|
| auto | Path to |
|
| Seconds before giving up on |
|
| Model for the |
The generate_image tool
Parameter | |
|
|
| full instructions |
|
|
| composition to preserve (attached first) |
| style images (attached after the base) |
| desired |
| allow replacing an existing file |
Returns path, format, width, height, operation, backend, model, warnings and log (Codex thread and log folder).
What we learned
Codex picks the resolution. Landscape requests came out 1672×941, unspecified ones 1024×1536.
sizeis not guaranteed: always checkwidth/height.One style reference is the sweet spot. Base alone keeps the composition but the finish stays close to the base; base + 1 reference keeps the composition and adds detail and light; base + 5 references loses the composition.
Full-scene references that look like the base hijack the composition.
Each image takes ~40–90 s and spends your plan's Codex limit.
The model is not reported by Codex.
openai-api backend (off by default)
For people who prefer the official Images API. It is billed separately from ChatGPT.
uv sync --extra apiThen register with -e IMAGEGEN_BACKEND=openai-api -e OPENAI_API_KEY=.... The key is read from the environment only and never written to disk.
Test without Claude Code
uv run python scripts/smoke_client.py # lists the tools
uv run python scripts/smoke_client.py scripts/example-args.json # generates one imageWith CODEX_HOME set in your shell if it is not ~/.codex.
Roadmap
Dedicated edit, clean_background, extract_pieces and create_variation operations. Today all of them are done with generate plus a base_image (see the skill).
License
Available Tools
1 toolgenerate_imageA
Generates an image and saves it to a local file.
operation: "generate" (the only operation in this version). prompt: full instructions (composition, style, what is forbidden). output_path: output .png file (relative to IMAGEGEN_ROOT or absolute). base_image: image whose composition must be preserved; attached first. reference_images: style images, attached after the base, in the given order. size: desired "WIDTHxHEIGHT" (e.g. "1536x864"). With the codex backend it is only requested in text and not guaranteed; check width/height in the result. overwrite: allows replacing an existing file.
Returns path, format, width, height, operation, backend, model, warnings and log.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| prompt | Yes | ||
| operation | Yes | ||
| overwrite | No | ||
| base_image | No | ||
| output_path | Yes | ||
| reference_images | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does substantial work: it discloses local file writing, relative or absolute output_path handling, overwrite replacement behavior, and the caveat that size may not be guaranteed on the codex backend. It still omits what happens when a file already exists without overwrite, directory creation behavior, and any permission or cost constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in one sentence, followed by a compact per-parameter list. Every line adds useful information, including format examples and backend caveats, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description usefully lists return fields: path, format, width, height, operation, backend, model, warnings and log. Given no annotations and seven parameters, it covers the key behavior and caveats well, though it leaves some edge-case behavior around existing files and filesystem setup unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning, and it does: it explains operation, prompt intent, output_path resolution, base_image composition role and attachment order, reference_images ordering, size format and backend caveat, and overwrite behavior. All seven parameters are meaningfully documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource: generates an image and saves it to a local file. It is clear for an image-generation tool, though there are no sibling tools to distinguish from and no broader task framing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through parameter roles: base_image for preserving composition, reference_images for style, and overwrite for replacing existing files. It does not explicitly say when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
generate_image
TDQS
Scored across 1 tool
With a single tool there is no possibility of misselection; the tool's purpose is unambiguous. An agent cannot confuse it with anything else on this server.
The lone name generate_image follows a clean verb_noun snake_case convention and reads predictably. No competing conventions exist to clash with it.
One tool is thin for a server surface, though the operation is deliberately scoped to a single 'generate' action per the description. All functionality (base image, references, size, overwrite) is packed into parameters rather than separate tools, which works but leaves the set feeling minimal.
Generation with optional base/reference images covers the core lifecycle, but there are no edit/variation/inpaint tools and no way to inspect or list prior outputs. The explicit 'only operation in this version' note signals acknowledged gaps.
Maintenance
Related MCP Connectors
Generate images from Claude, ChatGPT, Cursor and Codex with 12 top AI image models and 10 tools: up to 4 images per call, SVG vectorization, editing and more. Remote MCP with OAuth, no API keys. Pay per image, no subscription.
Generate images from Claude, ChatGPT, Cursor and Codex with 12 top AI image models. Up to 4 images per call, SVG vectorization, background removal, upscaling and image-to-video. Remote MCP with OAuth, no API keys.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceGenerates and edits images through the Codex CLI using an existing ChatGPT subscription, with queued jobs, progress reporting, and artifact URLs for MCP clients.346 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables generating images directly from Claude Code using the ChatGPT subscription's built-in Codex CLI and gpt-image-2, with no API key or separate credits.MIT
- AlicenseAqualityAmaintenanceEnables any MCP client to generate and edit images through ChatGPT's Codex backend, saving them locally with no API key or per-image billing.5346 npm8Apache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables Claude Code to generate and edit images through two MCP tools, routing requests to GPT Image models via a local CLIProxyAPI gateway using a ChatGPT subscription, with input validation and artifacts/receipts written to a specified directory.MIT