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

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.