Why does the Codex app expose image_gen while Codex CLI filters it out with the same configuration?

What version of Codex CLI is running?

codex-cli 0.146.0, which is the current release reported by the updater.

What environment was tested?

• macOS 26.5.2, x86_64
• iTerm2 3.6.11
• model: gpt-5.6-sol
• Responses-compatible custom model provider
• API-key authentication
• image_generation: stable and enabled
• codex doctor --json: overall status OK; configuration loaded and provider reachable

Provider URLs, keys, and unrelated local paths are intentionally omitted.

What issue are you seeing?

Could the Codex team explain why the Codex app and Codex CLI make different image-generation capability decisions when using the same account, model selection, and provider configuration?

In the Codex app, $imagegen can generate an image. In Codex CLI, the same workflow loads the bundled imagegen skill, but then reports:

The built-in image_gen tool described by the skill is not exposed in this session.

This is not an image API failure. Inspection of the CLI request shows that image_gen.imagegen is omitted from the tool list before the request is sent, so the configured provider never receives an image-generation request.

That makes the current UX especially confusing:

• the same Codex configuration is used by both surfaces;
• image_generation is reported as stable and enabled;
• the bundled skill explicitly prefers the built-in image_gen tool;
• the app exposes a working image-generation path;
• the CLI silently removes that path based on provider/authentication checks.

Steps to reproduce

1. Configure a Responses-compatible custom provider and authenticate with its API key.
2. Confirm that codex features list reports image_generation stable true.
3. In the Codex app, invoke $imagegen with an ordinary image prompt and observe that image generation is available.
4. From Codex CLI 0.146.0 using the same model/provider configuration, invoke $imagegen with the same prompt.
5. Observe that the skill loads, but the built-in tool is unavailable and no image-generation request is sent to the provider.

Why does the CLI reject this configuration?

The v0.146.0 source appears to gate image generation on OpenAI actor authorization or Codex-backend authentication:

https://github.com/openai/codex/blob/rust-v0.146.0/codex-rs/core/src/tools/spec_plan.rs#L363-L397

This raises several product-contract questions:

1. Is the app intentionally allowed to expose a hosted image tool independently of the configured model provider, while the CLI is intentionally forbidden from doing so?
2. If this is intentional, why does image_generation stable true not communicate that API-key/custom-provider sessions are excluded?
3. Why does the bundled skill enter a workflow that the CLI already knows cannot receive the required tool?
4. Is there a security or protocol reason that a provider cannot explicitly opt in to image generation?
5. What is the intended behavior for Bedrock and other third-party providers or credentials?

Expected behavior

The two Codex surfaces should apply a consistent, documented capability contract when they use the same configuration.

If custom-provider image generation is supported, Codex CLI should expose the tool or provide an explicit provider capability opt-in.

If it is intentionally unsupported, the CLI should report that restriction before loading the image-generation workflow, and the documentation and feature status should clearly explain why the app and CLI differ.

Please clarify whether this divergence is intentional product design, an incomplete custom-provider capability model, or a CLI bug.

Related reports

• #21640 reports that image generation works in the app but not the CLI.
• #24465 requests a custom-provider capability opt-in and documents the client-side auth gate.
• #30921 reports the same missing-tool symptom with a custom Responses endpoint.
• #19133 reports the same symptom with Azure OpenAI.