Codex app (new ChatGpt app) broken after big update

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

• #31882
• #31875
• #31870

Powered by Codex Action

yes azure deployments started demanding imagegen for some reason since 09.07.2026. probably azure fault because this happened for codex CLI, codex app, and codex vs extension.

codex cli needed reisntall and started working but vs extension is still tweaking

Same issue on Codex Desktop 26.707.62119 with custom Responses provider.

Config has:
[features]
image_generation = false
imagegenext = false

[[skills.config]]
path = "/Users/my-nickname/.codex/skills/.system/imagegen/SKILL.md"
enabled = false

codex features list reports image_generation stable false.

But Desktop-created thread still logs:
features=[..., ImageGeneration, ...]

And the actual /responses request still contains:
{"type":"namespace","name":"image_gen"}

The custom Responses endpoint returns:
Invalid Value: 'tools.namespace'. User-defined namespace 'image_gen' collides with an existing tool namespace.

CLI no longer sends image_gen after disabling image_generation, but Codex Desktop still does.

Additional reproduction: duplicate image_gen registration blocks unrelated approval-gated MCP tools

I can reproduce this on Codex Desktop 26.707.62119 with a custom Responses API provider. The impact is broader than image generation: the duplicate image tool registration breaks the approval-review path and therefore blocks otherwise unrelated MCP tools.

Environment

• Codex Desktop: 26.707.62119
• Platform: macOS / Apple Silicon
• Model: gpt-5.6-sol
• Custom model provider using wire_api = "responses"
• Guardian/on-request approvals enabled
• Incident date: 2026-07-13

Observed tool registration

There are no user-defined image_gen entries in ~/.codex/config.toml or the workspace config.

The same request exposes image generation through two runtime layers:

1. Top-level hosted tool: image_gen.imagegen
2. Nested developer tool visible to functions.exec: image_gen__imagegen

The local imagegen skill only references the built-in tool; it is not a second MCP/tool configuration.

Reproduction

1. Start a Desktop-created task using the custom Responses provider.
2. Confirm normal non-approval shell/read operations work.
3. Invoke an unrelated MCP read that requires approval because it accesses private workspace data:

``text
mcp__youdu__youdu_get_context({})
``

1. The MCP server is authenticated and its tools are registered correctly, but the call never reaches the MCP server.
2. The approval-review request fails first with:

``text
Invalid Value: 'tools'. Function 'image_gen.imagegen' conflicts with a hosted tool in the same request.
param: tools
status: 400
``

1. Explicitly approve the read operation and retry. The identical error occurs.
2. The same failure also occurs when requesting sandbox escalation for a read-only network command.
3. Attempting to add this report as a GitHub Issue comment through the GitHub connector is also blocked by the identical approval-review error.

Why this affects unrelated MCP tools

The failure appears to happen while constructing or sending the approval-review model request. That request includes both the hosted image-generation tool and a function/developer representation with the same namespace/name. Validation rejects the entire tools array before the requested MCP, GitHub, or shell action executes.

Youdu is therefore not the source of the error; it merely triggers the approval path. Any action requiring guardian approval may be blocked.

Expected behavior

• Hosted tools should not be duplicated as function/developer tools in the same Responses request.
• Approval-review subrequests should de-duplicate tools by hosted namespace/name, or omit tools irrelevant to the approval decision.
• An unrelated approved MCP read should execute normally.
• Desktop should respect the disabled image-generation feature for custom providers, if configured.

Actual behavior

Approval-gated tool execution is completely blocked, including unrelated MCP reads, GitHub writes, and sandbox escalation, even after explicit user approval.

Related issues

• Exact validation error: https://github.com/openai/codex/issues/32208
• Custom-provider / Desktop image-generation collision: https://github.com/openai/codex/issues/32155

Suggested destination: add this report as a comment to openai/codex#32155, since it contains current custom-provider evidence and links the exact-error report.

Additional provider-isolation reproduction from Codex CLI 0.144.4

I reproduced this with the same Codex-generated tool definition routed to two different backends.

Environment

• Codex CLI: 0.144.4
• macOS: 27.0, arm64
• Model: gpt-5.6-sol
• Azure resolved model: gpt-5.6-sol-2026-07-09
• Wire API: Responses
• Local OpenAI-compatible proxy used only to switch providers and capture/replay requests (https://github.com/sozercan/vekil)

Method

I captured the actual /responses payload generated by Codex. Its tools array contained exactly one client-defined image namespace:

{
  "type": "namespace",
  "name": "image_gen",
  "tools": [
    {
      "type": "function",
      "name": "imagegen"
    }
  ]
}

I then minimized the request to that exact captured namespace and replayed it without changing the tool schema.

Results

| Backend | Result |
|---|---|
| GitHub Copilot Responses | HTTP 200, completed |
| Azure Foundry GPT-5.6 Sol | HTTP 400 namespace collision |

Azure returned:

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

Controls against the same Azure deployment:

• A generic user namespace such as example.ping: HTTP 200
• A web_search tool: HTTP 200

This appears specific to the reserved image_gen namespace rather than a general rejection of namespace or hosted tools. The captured client request contained only one image_gen namespace, so it was not duplicated by the proxy or user configuration.

Workaround confirmed for CLI

image_generation is stable/default-enabled in Codex CLI 0.144.4. Setting:

[features]
image_generation = false

and starting a fresh Codex session removes the image_gen namespace from the outgoing request.

This looks related to #28464, but the provider A/B test suggests the collision is specifically exposed when Azure GPT-5.6 Sol reserves image_gen while Codex also advertises the client-executed extension under that name.

A possible fix would be for tool planning to suppress or rename the client-defined image_gen namespace when the selected provider/model already reserves it.

A temporary workaround is to remove requires_openai_auth or set it to false

Codex CLI：0.145.0-alpha.27
Codex Desktop：26.715.61943

Discovered by chance.
After ask the agent to do investigation, it finds some code which can explain why disable this config works:

//https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/spec_plan.rs
  fn image_generation_available(turn_context: &TurnContext) -> bool {
      if !turn_context
          .config
          .features
          .get()
          .enabled(Feature::ImageGeneration)
      {
          return false;
      }

      let capabilities = turn_context.provider.capabilities();
      if !capabilities.image_generation || !capabilities.namespace_tools {
          return false;
      }

      if !turn_context
          .model_info
          .input_modalities
          .contains(&InputModality::Image)
      {
          return false;
      }

      let provider = turn_context.provider.info();
      provider.uses_openai_actor_authorization()
          || (provider.requires_openai_auth
              && turn_context
                  .auth_manager
                  .as_deref()
                  .is_some_and(AuthManager::current_auth_uses_codex_backend))
  }


  for executor in executors.iter().cloned() {
      let tool_name = executor.tool_name();

      // ...

      if tool_name == ToolName::namespaced(IMAGE_GEN_NAMESPACE, IMAGEGEN_TOOL_NAME)
          && !image_generation_available(turn_context)
      {
          continue;
      }

      // ...
  } 

The trade off is cannot open OpenAI plugins marketplace inside the Codex desktop. Codex cli is not affected.