Codex 5.1 , 5.2 , 5.3 , 5.4 | Friends of the Crustacean 🦞🤝 | Page 1

full quail Apr 14, 2026, 7:08 PM

#

Codex 5.1 , 5.2 , 5.3 , 5.4 all are getting {"detail":"The 'gpt-5.3-codex-spark' model is not supported when using Codex with a ChatGPT account."} and also gemini 0autho

sinful valeBOT Apr 14, 2026, 7:08 PM

#

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

chrome badgeBOT Apr 14, 2026, 7:10 PM

#

First, what does openclaw --version show?

That specific error usually means route mismatch:

openai-codex/* = ChatGPT/Codex OAuth
openai/* = direct OpenAI API key

So if you signed in with ChatGPT/Codex, but the model is set to openai/gpt-5.4 or a bare gpt-5.4, it can blow up like this. Also, gpt-5.3-codex-spark is entitlement-dependent on the Codex OAuth side.

Try these:

openclaw models status
openclaw models list --provider openai-codex
openclaw config set agents.defaults.model.primary openai-codex/gpt-5.4

#

If you want direct OpenAI instead, use OPENAI_API_KEY and the openai/* route.

For Gemini OAuth, use the Gemini CLI provider:

openclaw models auth login --provider google-gemini-cli --set-default

Notes:

gemini must be installed and on PATH
if login works but requests fail, set GOOGLE_CLOUD_PROJECT or GOOGLE_CLOUD_PROJECT_ID
that OAuth path is unofficial and some accounts get restricted

Docs:

#

https://docs.openclaw.ai/concepts/oauth

If you paste:

openclaw --version
openclaw models status
your current agents.defaults.model.primary

…I can tell you exactly which piece is wrong.

lethal dove Apr 14, 2026, 8:45 PM

#

@chrome badge I'm not the OP but am having the same issues today. Is it okay to jump in?

chrome badgeBOT Apr 14, 2026, 8:45 PM

#

Yep, please jump in.

If you’re seeing the same thing, paste these and I’ll compare it against the OP’s case:

openclaw --version
openclaw models status
openclaw models list --provider openai-codex

And if Gemini OAuth is also failing, include the exact Gemini error too. That’ll make it a lot faster to tell whether this is the same route/auth issue or a separate one.

lethal dove Apr 14, 2026, 8:50 PM

#

Giving you config in two messages, Krill. Wait for the second to respond!

version: OpenClaw 2026.4.14 (323493f)

models status:
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.1-codex-mini
Fallbacks (14): openai-codex/gpt-5.1, openai-codex/gpt-5.2, openai-codex/gpt-5.1-codex-max, openai-codex/gpt-5.4, openai-codex/gpt-5.3-codex, lmstudio/zai-org/glm-4.7-flash, lmstudio/qwen/qwen3.5-9b, lmstudio/medina-qwen3.5-27b-openclaw, lmstudio/qwen/qwen3-coder-30b, lmstudio/nousresearch/hermes-4-70b, lmstudio/nvidia/nemotron-3-nano, lmstudio/qwen2.5-coder-32b-instruct, lmstudio/qwen/qwen2.5-vl-7b, lmstudio/minimax-m2.5
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (15): openai-codex/gpt-5.1-codex-mini, openai-codex/gpt-5.4, openai-codex/gpt-5.1, openai-codex/gpt-5.2, openai-codex/gpt-5.1-codex-max, openai-codex/gpt-5.3-codex, lmstudio/zai-org/glm-4.7-flash, lmstudio/qwen/qwen3.5-9b, lmstudio/medina-qwen3.5-27b-openclaw, lmstudio/qwen/qwen3-coder-30b, lmstudio/nousresearch/hermes-4-70b, lmstudio/nvidia/nemotron-3-nano, lmstudio/qwen2.5-coder-32b-instruct, lmstudio/qwen/qwen2.5-vl-7b, lmstudio/minimax-m2.5

#

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (2)

lmstudio effective=models.json:lm...io | models.json=lm...io | source=models.json: ~/.openclaw/agents/main/agent/models.json
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=2, token=0, api_key=0) | openai-codex:default=OAuth, openai-codex:f__redacted__@redacted.com=OAuth (redacted)

OAuth/token status

openai-codex usage: 5h 92% left ⏱3h 12m · Week 10% left ⏱2d 19h
- openai-codex:default ok expires in 8d
- openai-codex:f__redacted__@redacted.com (redacted) ok expires in 10d

–––

Model Input Ctx Local Auth Tags
openai-codex/gpt-5.1-codex-mini text+image 266k no yes default,configured
openai-codex/gpt-5.1 text+image 266k no yes fallback#1,configured
openai-codex/gpt-5.2 text+image 266k no yes fallback#2,configured
openai-codex/gpt-5.1-codex-max text+image 266k no yes fallback#3,configured
openai-codex/gpt-5.4 text+image 1025k no yes fallback#4,configured
openai-codex/gpt-5.3-codex text+image 266k no yes fallback#5,configured

#

@chrome badge that is my config. I don't have Google like the OP but I'm having the same issue with codex. Thanks for your help!

chrome badgeBOT Apr 14, 2026, 8:51 PM

#

This is really helpful, thanks. Your current config/auth looks sane.

The big tell is this part: your live catalog shows

openai-codex/gpt-5.1-codex-mini
openai-codex/gpt-5.1
openai-codex/gpt-5.2
openai-codex/gpt-5.1-codex-max
openai-codex/gpt-5.4
openai-codex/gpt-5.3-codex

…but not gpt-5.3-codex-spark.

So if a thread is still erroring on spark, I’m pretty suspicious that the failing chat/session has a stale session model override or older session state pinned somewhere, not a current auth problem.

Please try this in the exact failing chat/thread:

#

/model status
/model openai-codex/gpt-5.4

If it still errors, force a fresh session:

/new openai-codex/gpt-5.4

Why I’m leaning that way:

your OAuth is healthy
quota looks fine
your configured/default model is not Spark
your current discovered model list does not include Spark

#

So the next check is whether that specific session is carrying old model state.

If you can, paste the output of /model status from the failing thread. That should show what model the session is actually trying to use.

Docs:

And yep, the Gemini OAuth bit is probably separate, send the exact Gemini error once you have it.

#

Yep, I was talking about your Codex side, not Google.

From what you pasted, I don’t see a bad global config. That’s why I think this is most likely stale session state in the failing thread.

Next thing to try, in the exact thread that errors:

/model status
/model openai-codex/gpt-5.4

If that still throws the Spark error:

/new openai-codex/gpt-5.4

#

If a fresh session works, we’ve basically confirmed it was the old session carrying the wrong model. If you paste /model status from the broken thread, I can sanity check it.

lethal dove Apr 14, 2026, 8:52 PM

#

I did just install codex yesterday, intending to wire it in and use as a harness. Now it looks like I have 2 Auth profiles for my main agent. Are you sure this isn't the root cause, @chrome badge

chrome badgeBOT Apr 14, 2026, 8:52 PM

#

I don’t think having two OpenAI Codex OAuth profiles by itself is the root cause.

That part is actually supported. OpenClaw can keep multiple profiles for the same provider, and it pins one profile per session rather than rotating every request.

What makes me doubt that’s the main issue:

both profiles show healthy
quota is visible
your active catalog does not include Spark
the error itself is a model entitlement/support error, not an “auth expired / invalid token” style error

So: two profiles could affect which account/profile gets picked, but the mere existence of two profiles should not magically rewrite everything to gpt-5.3-codex-spark.

If you want to rule it out cleanly, pin one profile explicitly in the broken thread:

#

/model openai-codex/gpt-5.4@openai-codex:default

Then, if needed:

/new openai-codex/gpt-5.4@openai-codex:default

If that still errors with Spark, I’d treat it as session/model state, not “you have 2 auth profiles”.

Docs:

If you paste /model status from the failing thread next, that should settle it.

lethal dove Apr 14, 2026, 8:56 PM

#

/model status shows exactly what it did before so I won't paste that in here. However, when I started a new session with /new openai-codex/gpt-5.4, I got this response. Twice in a row:

LLM request failed: DNS lookup for the provider endpoint failed.

chrome badgeBOT Apr 14, 2026, 8:56 PM

#

Ah, that’s a different error, and honestly a useful clue.

A fresh /new openai-codex/gpt-5.4 failing with:

DNS lookup for the provider endpoint failed

means the new session is no longer stuck on the old Spark model state. Now it’s failing earlier, at network/endpoint resolution.

So I’d split it like this:

old thread: likely stale session/model state
new thread: likely DNS / custom endpoint / proxy issue

Two quick checks:

#

openclaw config get models.providers.openai-codex

and from the gateway host:

curl -I https://chatgpt.com

What I’m looking for:

if models.providers.openai-codex has a weird baseUrl, that’s probably the culprit
if curl can’t resolve chatgpt.com, it’s machine DNS/network
if curl works, paste the baseUrl/api lines from /model status

One more important thing since you mentioned the harness: if your goal is the Codex harness, that is a separate route from openai-codex/*.

#

openai-codex/* = ChatGPT/Codex OAuth provider
codex/* = bundled Codex harness route

Docs:

If you paste the models.providers.openai-codex block next, I can usually spot endpoint weirdness pretty fast.

lethal dove Apr 14, 2026, 9:01 PM

#

results:

openclaw config get models.providers.openai-codex = Config path not found: models.providers.openai-codex

curl -I https://chatgpt.com
HTTP/2 103 link: </cdn/assets/conversation-small-ngtpy4v2.css>; as=style; rel=preload, </cdn/assets/root-g7rg8dfj.css>; as=style; rel=preload

`HTTP/2 403
date: Tue, 14 Apr 2026 20:58:35 GMT
content-type: text/html; charset=UTF-8
accept-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
cf-mitigated: challenge
critical-ch: Sec-CH-UA-Bitness, Sec-CH-UA-Arch, Sec-CH-UA-Full-Version, Sec-CH-UA-Mobile, Sec-CH-UA-Model, Sec-CH-UA-Platform-Version, Sec-CH-UA-Full-Version-List, Sec-CH-UA-Platform, Sec-CH-UA, UA-Bitness, UA-Arch, UA-Full-Version, UA-Mobile, UA-Model, UA-Platform-Version, UA-Platform, UA
cross-origin-embedder-policy: require-corp
cross-origin-opener-policy: same-origin-allow-popups
cross-origin-resource-policy: same-origin
origin-agent-cluster: ?1
permissions-policy: accelerometer=(),browsing-topics=(),camera=(),clipboard-read=(),clipboard-write=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()
referrer-policy: strict-origin-when-cross-origin
server-timing: chlray;desc="9ec5a120dc174cb3"
x-content-type-options: nosniff
x-frame-options: ...

#

SAMEORIGIN
strict-transport-security: max-age=31536000; includeSubDomains; preload
set-cookie: __cf_bm=CFwJkZqj7FRn1p8Us__REDACTED__zGZU44Jd9hwZ6G5; HttpOnly; Secure; Path=/; Domain=chatgpt.com; Expires=Tue, 14 Apr 2026 21:28:35 GMT
report-to: {"group":"cf-nel","max_age":604800,"endpoints":[{"url":"REDACTED"}
nel: {"report_to":"cf-nel","success_fraction":0.01,"max_age":604800}
server: cloudflare
cf-ray: 9ec5a120dc174cb3-SLC
alt-svc: h3=":443"; ma=86400`

chrome badgeBOT Apr 14, 2026, 9:02 PM

#

Nice, that narrows it down a lot.

Two useful takeaways:

Config path not found: models.providers.openai-codex is fine here, it means you do not have a custom OpenAI Codex endpoint override.
curl -I https://chatgpt.com returning 403 is actually good news. It proves the box can resolve DNS and reach ChatGPT over HTTPS.

So the generic OpenClaw message is probably masking one of these:

a different hostname than chatgpt.com failed
a transient resolver error (EAI_AGAIN / ENOTFOUND) inside the runtime
less likely, a duplicate/stale gateway/runtime is handling some requests

At this point, the most useful thing is the gateway log around the failure. I’d do:

#

openclaw logs --limit 200 --plain

Reproduce the failure once, then paste the lines around it, especially anything mentioning:

ENOTFOUND
EAI_AGAIN
openai-codex
chatgpt
backend-api

If the log looks weird or inconsistent after that, then I’d also check:

openclaw gateway status --deep

#

That can catch stale/parallel gateway installs.

So, short version: this does not look like a bad openai-codex config key anymore. It now looks like a runtime/network-path issue, and the logs should finally tell us which hostname is actually failing.

#

Yep, that’s still just the curl output, and it’s enough to show the host can reach chatgpt.com.

The next thing I need is OpenClaw’s own log output, not more headers.

Please do this:

trigger the failure once
then run:

openclaw logs --limit 200 --plain

Paste the chunk around the failure. That’s what should show the real hostname/error behind the sanitized:

LLM request failed: DNS lookup for the provider endpoint failed.

#

You can redact emails/tokens, but keep any lines with:

ENOTFOUND
EAI_AGAIN
openai-codex
chatgpt
backend-api

We’re close, I just need the actual runtime error now.

lethal dove Apr 14, 2026, 9:06 PM

#

I have a few matching errors with this shape. Gateway status --deep shows only my one gateway install and reports not issues.

2026-04-14T21:02:30.017Z warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"1fd29c1e-e05b-40d8-b196-d210073293ab","isError":true,"error":"LLM request failed: DNS lookup for the provider endpoint failed.","failoverReason":null,"model":"gpt-5.1-codex-mini","provider":"openai-codex","rawErrorPreview":"<html>\n <head>\n <meta name="viewport" content="width=device-width, initial-scale=1" />\n <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction:column;gap:2rem;height:100%;justify-content:center;width:100%}@keyframes enlarge-appear{0%{opacity:0;transform:scale(75%) rotate(-90deg)}to{opacity:1;transform:scale(100%) rotate(0deg)}}.lo…","rawErrorHash":"sha256:2ff9cc31958d","providerRuntimeFailureKind":"unknown"} embedded run agent end

chrome badgeBOT Apr 14, 2026, 9:06 PM

#

Aha, that log is the real clue.

This does not look like DNS anymore.

Why:

rawErrorPreview is HTML
your earlier curl showed cf-mitigated: challenge
so openai-codex is very likely getting a Cloudflare challenge/block page from ChatGPT, and OpenClaw is mislabeling it as DNS

So the likely chain is:

openai-codex request → Cloudflare challenge HTML → OpenClaw sanitizes badly → user sees fake “DNS lookup failed”

That also explains why this felt weird the whole time.

What I’d try next:

Disable VPN / proxy / WARP / filtering DNS / adblock network layers

#

If this is running on a VPS/datacenter IP, try from a home/residential network
Retry openai-codex after that
If your actual goal is the Codex harness, use the codex/* path, not openai-codex/*
If you want the most boring/reliable OpenAI route, use openai/* with an API key

So at this point I’d stop chasing “two auth profiles” or “DNS”. The bigger issue looks like ChatGPT/Codex OAuth traffic getting challenged upstream.

And honestly, the misleading DNS message itself looks like a real bug. If you want maintainer eyes on it, please file an issue with that log snippet here:
https://github.com/openclaw/openclaw/issues

One question that would help: is your gateway running on a VPS/server IP or on your local home machine?

lethal dove Apr 14, 2026, 9:07 PM

#

local machine.

chrome badgeBOT Apr 14, 2026, 9:07 PM

#

That helps.

If it’s on a local machine, then a datacenter IP block is less likely. I’d now suspect something on the network path more than the host:

VPN
Cloudflare WARP
proxy
NextDNS / AdGuard / Pi-hole style filtering
corporate/school network weirdness

Fastest test: temporarily switch to your phone hotspot and try the same fresh session again.

If hotspot works, you’ve basically confirmed it’s your normal network path getting challenged.

If hotspot still fails, then I’d stop spending time on openai-codex/* and pivot to what you originally wanted anyway: the Codex harness route (codex/*) instead of the ChatGPT OAuth route (openai-codex/*).

So at this point my recommendation would be:

lethal dove Apr 14, 2026, 9:07 PM

#

and I don't care about the codex harnass at the moment; i just need my agent to be able to talk to me again

chrome badgeBOT Apr 14, 2026, 9:07 PM

#

try hotspot / disable VPN-style layers
if still broken, switch focus to codex/*
keep that log snippet for a GitHub issue, because the fake DNS message is still a real bug

If you want, I can help you sanity-check the harness path next.

lethal dove Apr 14, 2026, 9:08 PM

#

It's not the network, network is fine.

chrome badgeBOT Apr 14, 2026, 9:08 PM

#

Got it. Then don’t spend another minute on openai-codex right now.

The fastest way to get your agent talking again is:

switch to any non-openai-codex model
start a fresh session
come back to Codex later

Since you already have LM Studio models configured, I’d do this right now in chat:

/model lmstudio/qwen/qwen3-coder-30b
/new

Or just open the /model picker and choose anything that is not openai-codex/*.

#

If that works and you want to make it stick:

openclaw models set lmstudio/qwen/qwen3-coder-30b

So the short version is: your agent is probably fine, the openai-codex route is the broken part. Move off that route for now and you should be able to talk again.

Docs:

If you want, after you try one local model, tell me which one worked and I’ll help you make that the clean temporary default.

#

Fair, let me phrase that better: I’m not saying your internet is broken.

I’m saying the openai-codex path is getting back an HTML challenge/block page, so that specific route is failing even though the rest of your network works.

At this point, the practical choices are:

Fastest recovery: switch to any non-openai-codex model so your agent can reply again
Stay on OpenAI: use the direct openai/* API-key route instead of openai-codex/*

I’d recommend option 1 right now, because it gets you unstuck immediately.

Example:

/model lmstudio/qwen/qwen3-coder-30b
/new

#

Or if you want cloud OpenAI instead of local, switch to openai/* with an API key.

So the key point is: whether we call it “network” or not, openai-codex is the broken leg here. Moving off that route is the fastest way to get your agent talking again.

lethal dove Apr 14, 2026, 9:09 PM

#

Krill, maybe I need to rollback to an earlier version. I just updated and it's been a hot mess ever since. What is the most recent version that includes talk, task flow, dreaming and doesn't have issues with chatgpt models?

chrome badgeBOT Apr 14, 2026, 9:10 PM

#

If you want a single rollback target to try first, I’d try 2026.4.11.

Why that one:

it’s recent
it still has Talk, Task Flow, and Dreaming
the changelog for 2026.4.11 includes an explicit OpenAI/Codex OAuth fix (invalid_scope on new Codex sign-ins)

I would not blindly jump much older than that first.

One important caveat though: the log you pasted earlier looked like an upstream HTML challenge page, not a clean OpenClaw auth/config bug. So a rollback might not fix this if the real problem is the ChatGPT/Codex OAuth route getting challenged.

So my honest recommendation is:

Try 2026.4.11
test immediately
if you still see the same HTML/challenge-shaped failure, stop rolling back, because it probably isn’t a version-only problem

#

If you want the “best bet” answer, it’s 2026.4.11.

lethal dove Apr 14, 2026, 9:11 PM

#

please remind me of the correct syntax to pin that version

chrome badgeBOT Apr 14, 2026, 9:11 PM

#

Yep. If you want to install that exact version, use:

pnpm add -g openclaw@2026.4.11

Then verify + restart:

openclaw --version
openclaw gateway restart

If you prefer using the updater for a one-off downgrade/test, this also works:

#

openclaw update --tag openclaw@2026.4.11

Small difference:

pnpm add -g openclaw@2026.4.11 = explicit install of that version
openclaw update --tag openclaw@2026.4.11 = one-off updater target, not a permanent “stay here forever” pin

Docs:

lethal dove Apr 14, 2026, 9:15 PM

#

Krill, the agent is running on a local model. I'll try to roll back to 4.11 and will report back.

chrome badgeBOT Apr 14, 2026, 9:16 PM

#

Sounds good.

And yeah, if the agent is actually running on a local model but you’re still seeing openai-codex-shaped failures, that’s another sign something weird is being resolved/routed under the hood, so your rollback test should be pretty informative.

When you report back, the two most useful things will be:

openclaw --version
/model status

If 4.11 still does the same thing, paste the new log snippet too and we can narrow it down from there.

lethal dove Apr 14, 2026, 9:20 PM

#

Krill, is there a way to wipe my current Oauth profiles for chatgpt / codex and start over?

chrome badgeBOT Apr 14, 2026, 9:21 PM

#

Yep.

If you want to wipe just the ChatGPT/Codex OAuth profiles and start fresh, the cleanest path is:

openclaw capability model auth logout --provider openai-codex
openclaw models auth login --provider openai-codex --set-default

If you want the nuclear option for the main agent, back up the auth store first, then move it out of the way:

mv ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.json.bak

Then re-login whatever providers you actually want.

#

One important gotcha: if you also have the legacy import file, old OAuth can come back in on first use. So for a truly clean restart, also move this if it exists:

mv ~/.openclaw/credentials/oauth.json ~/.openclaw/credentials/oauth.json.bak

Then re-auth:

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

I’d start with the provider logout command first, since it’s less destructive.

lethal dove Apr 14, 2026, 10:03 PM

#

@chrome badge I had to go with the nuclear option. I did that first and then redid the OAuth flow. That didn’t change the agent’s behavior. Then I rolled back to 2026.4.11. And my agent still responds with “LLM request failed: DNS lookup for the provider endpoint failed.”

chrome badgeBOT Apr 14, 2026, 10:04 PM

#

That’s actually a really useful result.

At this point you’ve ruled out:

stale OAuth profiles
bad saved tokens
duplicate gateway installs
simple version regression between 2026.4.14 and 2026.4.11

So I would stop doing rollback roulette here.

What’s left is basically:

the openai-codex route is getting blocked/challenged upstream, or
OpenClaw is misrouting a session through openai-codex when it should not be

If your goal is just to get the agent usable again, I’d do this as a clean test:

#

/model <one of your lmstudio models>
/new
/model status

If /model status still says openai-codex after you explicitly switched to LM Studio, then that’s a real routing bug, not auth.

And for the Codex issue itself, I think this is now GitHub-issue territory. Include:

openclaw --version
that you tested 2026.4.14 and 2026.4.11
that you wiped auth-profiles.json and re-authed
the log line with rawErrorPreview showing HTML
that the surfaced error says fake DNS failure

Issue link:

#

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

If you want, I can help you write the exact issue body in one paste-ready message.

opal sky Apr 14, 2026, 10:39 PM

#

I found this fix if you want to give it a try https://github.com/openclaw/openclaw/issues/66674#issuecomment-4247471212

chrome badgeBOT Apr 14, 2026, 10:40 PM

#

Nice find, and yeah, that workaround looks plausible.

I checked the config shape, and those are real keys:

models.providers.openai-codex.api
models.providers.openai-codex.baseUrl
models.providers.openai-codex.models[]

So if someone wants to try it, I’d treat it as a temporary workaround:

{
  models: {
    providers: {
      "openai-codex": {
        api: "openai-codex-responses",
        baseUrl: "https://chatgpt.com/backend-api",

#

        models: [
          { id: "gpt-5.4", name: "gpt-5.4", api: "openai-codex-responses" }
        ]
      }
    }
  }
}

Then:

openclaw gateway restart

One caveat: this intentionally adds a models.providers.openai-codex override, and the docs specifically warn that this can shadow the built-in Codex OAuth path. So I would not call it the ideal long-term fix, but it absolutely seems worth testing for this thread’s issue.

#

If somebody here tries it and it works, that’s a really strong signal that the breakage is in transport selection/routing, not real DNS.

lethal dove Apr 15, 2026, 12:03 AM

#

@chrome badge I figured it out: Codex doesn't support any 5.1 models anymore. So the deprecated models must be removed from openclaw.json. Once I got that figured out, I was able to update again to 2026.4.12 and my agent is back up and running. https://developers.openai.com/codex/models

#Codex 5.1 , 5.2 , 5.3 , 5.4

version: OpenClaw 2026.4.14 (323493f)

I have a few matching errors with this shape. Gateway status --deep shows only my one gateway install and reports not issues.