›_ Codex Issues
Codex Issues / #28464

imagegenext registers image_gen and collides with the built-in image_gen namespace

Open 💬 3 comments Opened Jun 16, 2026 by JinchengGao-Infty
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.140.0

What subscription do you have?

ChatGPT auth. The exact subscription should not be material here because the request fails at tool namespace validation before image generation runs.

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2 3.6.6

Codex doctor report

Summary:

Codex Doctor v0.140.0 · macos-aarch64
16 ok · 1 idle · 3 notes · 1 warn · 0 fail degraded
auth mode: ChatGPT
model provider: OpenAI
wire API: responses

I am not pasting the full JSON report because it contains many local filesystem paths, but I can provide a redacted full report if useful.

What issue are you seeing?

Enabling the under-development imagegenext feature causes requests to fail with a 400 before the model can run:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "Invalid Value: 'tools.namespace'. User-defined namespace 'image_gen' collides with an existing tool namespace.",
    "param": "tools.namespace"
  },
  "status": 400
}

This makes the session unusable until imagegenext is disabled and a fresh session is started.

The issue appears to be that the standalone image generation extension registers a user-defined namespace named image_gen, while the platform now has a built-in/reserved image_gen namespace.

What steps can reproduce the bug?

  1. Use Codex CLI 0.140.0 with ChatGPT auth and a model/account where stable image generation is available.
  2. Enable the experimental standalone image generation extension:

``toml
[features]
image_generation = true
imagegenext = true
``

image_generation is stable/default-on in my environment; the important override is imagegenext = true.

  1. Start a new Codex CLI session.
  2. Send a normal prompt, or ask for image generation.

Actual result: the request fails with the tools.namespace 400 shown above.

Workaround:

[features]
imagegenext = false

After disabling imagegenext and starting a fresh session, the stable built-in image_gen path can be used again.

What is the expected behavior?

Enabling imagegenext should not make all requests fail with a namespace collision.

Possible fixes:

  • Do not register the standalone image generation extension under a user-defined namespace that collides with the platform built-in image_gen namespace.
  • Automatically disable or ignore imagegenext when the platform built-in image_gen namespace is present.
  • Rename the standalone extension namespace, or otherwise treat image_gen as reserved before building the tool list.

Additional information

I searched existing issues for the exact error and for imagegenext; I did not find this specific image generation namespace collision.

There is a related namespace-collision issue for standalone_web_search: #28168. This looks like the same class of bug, but for image generation.

Source inspection on current main (1e015884c51ae2d2ec6aecf5638564d7d7ff4a15) shows:

  • codex-rs/core/src/tools/spec_plan.rs has const IMAGE_GEN_NAMESPACE: &str = "image_gen";
  • codex-rs/core/src/tools/spec_plan.rs checks standalone_image_generation_available(...) and has a TODO to remove hosted image generation once the standalone extension is ready.
  • codex-rs/features/src/lib.rs marks image_generation as stable/default-enabled and imagegenext as under-development/default-disabled.

That matches the observed workaround: leave stable image_generation enabled, but keep imagegenext disabled.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #28168

Powered by Codex Action

JinchengGao-Infty · 2 months ago

Thanks for the duplicate check. I think this is related to #28168 but not an exact duplicate.

#28168 is for standalone_web_search registering web.run, while this issue is for imagegenext registering image_gen.imagegen. The repro uses a different feature flag, a different reserved namespace, and
reproduces on 0.140.0.

Also, current main already appears to have image-generation mutual exclusion logic that avoids adding the hosted image-generation tool when the standalone image extension is available. The observed failure still
happens because the user-defined namespace itself is image_gen, which now appears to be reserved by the platform.

So this may share the same root class as #28168, but it is a separate image-generation instance and should probably remain open unless there is a single umbrella issue for reserved namespace collisions.

MakenRosa · 2 months ago

I checked the current tool planning and the collision is very likely caused by the standalone image generation extension intentionally advertising the same namespace the hosted Responses image tool reserves.

Relevant pieces:

  • codex-rs/core/src/tools/spec_plan.rs defines IMAGE_GEN_NAMESPACE = "image_gen" and IMAGEGEN_TOOL_NAME = "imagegen".
  • Hosted image generation is added by create_image_generation_tool("png") when image_generation_tool_enabled() is true and standalone_image_generation_available() is false.
  • The standalone extension is allowed through add_extension_tool_executors() when the tool name is image_gen.imagegen and standalone_image_generation_model_visible() is true.
  • codex-rs/ext/image-generation/src/lib.rs also defines IMAGE_GEN_NAMESPACE = "image_gen".
  • codex-rs/ext/image-generation/src/tool.rs::imagegen_tool_spec() returns ToolSpec::Namespace(ResponsesApiNamespace { name: "image_gen", tools: [imagegen], ... }).

The extension test confirms this current contract:

cargo test -p codex-image-generation-extension uses_reserved_image_gen_namespace --lib

Result:

test tool::tests::uses_reserved_image_gen_namespace ... ok

So the code is doing exactly what the API error says: it sends a user-defined namespace named image_gen. The planner avoids sending the hosted image-generation tool when the standalone extension is available, but that does not avoid a namespace reservation conflict if the API treats image_gen as a built-in/reserved namespace regardless of whether the hosted tool spec is included in the request.

Fix direction: imagegenext should not expose a user-defined namespace called image_gen unless the API explicitly supports clients defining that reserved namespace. The surgical options I see are:

  1. Rename the extension namespace, for example image or image_generation_ext, and update the planner's ToolName::namespaced(...) checks plus tests.
  2. Keep image_gen only for the hosted tool path and suppress the extension whenever that namespace is reserved by the target provider/model.
  3. Add a provider capability that explicitly says "client may define image_gen namespace" before letting the extension through.

Given imagegenext is still under-development and disabled by default, a namespace rename seems lowest-risk. It would preserve stable hosted image generation and unblock people testing the extension with image_generation=true.