openai image generation using wrong api endpoint

[sturdy grove]

openclaw 2026.5.18.beta-7
@split panther

I previously set up a paid credit api key for openai, so I could use the image generator and realtime voice model, before these were explicitly supported via oAuth in Openclaw.

But now, when I try to use the image generation tool with config:

      "imageGenerationModel": {
        "primary": "openai/gpt-image-2",

I get geo-blocked, but the returned message implies OC is using the wrong endpoint.

OpenClaw has two OpenAI image paths:
direct OpenAI Images API: https://api.openai.com/v1/images/generations,
Codex OAuth path: https://chatgpt.com/backend-api/codex/responses,
,
The direct path throws errors labelled OpenAI image generation failed.,
The Codex path throws errors labelled OpenAI Codex image generation failed.,
The failure event text said: OpenAI image generation failed (HTTP 403): Country, region, or territory not supported.,
Therefore it matched the direct Images API branch, not the Codex branch.,

Image generation succeeds when using codex cli directly. Or even when the agent uses codex cli tool to request the image.

Since the updates have refactored a lot of the config files... auth-profiles.json, for example, is almost empty now. I'm having trouble tracking down the auth flow and valid vs legacy config.

How can I stop OpenClaw from using the paid credit api endpoint when I have oAuth already set up, but I also have API key auth set up for other purposes?

[meager pulsar]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[split panther]

I checked the current source/docs. Your read of the error label is right: OpenAI image generation failed (HTTP 403) is the direct OpenAI Images API path, not the Codex OAuth path.

Current intended behavior is:

• agents.defaults.imageGenerationModel.primary: "openai/gpt-image-2" can use either OPENAI_API_KEY or OpenAI Codex OAuth.
• On current main, if an openai-codex OAuth profile is configured, openai/gpt-image-2 should route through https://chatgpt.com/backend-api/codex/responses before probing OPENAI_API_KEY.
• But OpenClaw intentionally stays on the direct Images API if you have explicit direct OpenAI config, because that signals “use this OpenAI provider config”.

So I’d check these in order:

openclaw models auth login --provider openai-codex --set-default
openclaw models status
openclaw doctor

Then inspect your config for explicit direct OpenAI provider/profile entries. These can force the direct Images API route even when Codex OAuth exists:

[split panther]

auth: {
  profiles: {
    "openai:...": { provider: "openai", ... }
  }
}

models: {
  providers: {
    openai: {
      apiKey: "...",
      baseUrl: "https://api.openai.com/v1",
      api: "...",
      headers: { ... },
      authHeader: false,
      request: { ... }

[split panther]

    }
  }
}

For your case, the clean setup is usually: keep OPENAI_API_KEY available for realtime/direct OpenAI things, but remove the explicit models.providers.openai image/provider override and any auth.profiles entry whose provider is openai, if you want openai/gpt-image-2 to prefer Codex OAuth. Leave the openai-codex OAuth profile in place.

One more important bit: the changelog on current main has a fix specifically for this: “route openai/gpt-image-2 through configured Codex OAuth directly when an openai-codex profile is active, instead of probing OPENAI_API_KEY first.” If you remove explicit direct config and beta-7 still hits /v1/images/generations, that sounds like you’re on a build just before/without that fix, or there’s a stale legacy config shadowing routing. In that case, please file it with your redacted openclaw status --all, openclaw doctor, and the relevant redacted provider/auth-profile snippets: https://github.com/openclaw/openclaw/issues

Docs I checked:
https://docs.openclaw.ai/gateway/configuration
https://docs.openclaw.ai/concepts/oauth
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/gateway/doctor

[sturdy grove]

There is currently no explicit providers block for openai in config. But there is an enabled plugin:

Verified config shows:

plugins.allow includes openai and codex,
plugins.entries.openai.enabled = true,
plugins.entries.codex.enabled = true,

openclaw models status
shows:

- openai effective=env:sk-p*redacted* | env=sk-p*redaccted* | source=env: OPENAI_API_KEY
- openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:[e-mail]=OAuth ([e-mail]) | synthetic=plugin-owned | source=codex-app-server

Do I need to disable the openai plugin?

[split panther]

No, I would not disable the openai plugin for this.

The openai plugin is what registers the openai/gpt-image-2 image-generation provider. Disabling it is likely to remove/break that provider path rather than make it use Codex OAuth.

Based on the status you pasted, you have the shape that should work with the new routing:

• openai has OPENAI_API_KEY
• openai-codex has an OAuth profile
• no explicit models.providers.openai override

On current main, that should prefer the Codex OAuth image route for openai/gpt-image-2 when the Codex profile is present. So if beta-7 still sends the image request to /v1/images/generations, I think you are hitting the pre/failing edge of the fix rather than a config issue.

I’d do two checks:

openclaw doctor

[split panther]

openclaw logs --follow

Look for either:

• doctor warning about legacy models.providers.openai-codex overrides shadowing the built-in Codex path
• log line like image auth selected: provider=openai-codex ... transport=codex-responses

If you never see that log line and it still says OpenAI image generation failed, then this is worth filing as a bug against beta-7 with the redacted models status block you pasted. The expected behavior is exactly what you want: keep OPENAI_API_KEY for direct OpenAI uses, while openai/gpt-image-2 routes through Codex OAuth when an openai-codex profile is active.

Issue link: https://github.com/openclaw/openclaw/issues

[sturdy grove]

openclaw doctor fixed the routing, by removing legacy provider definition blocks from various config files.

[split panther]

Nice, glad doctor caught it. That lines up with the legacy provider override warning: those old blocks can shadow the built-in Codex OAuth route even when the current visible config looks mostly right.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person who hits this.