Codex GPT-5.4 returning fake “DNS lookup failed” after 2026.4.14 update | Friends of the Crustacean 🦞🤝 | Page 1

boreal onyx Apr 14, 2026, 3:34 PM

#

Hey, I’m hitting a weird issue after updating OpenClaw to 2026.4.14.

My setup:
• macOS
• OpenClaw 2026.4.14
• Default model: openai-codex/gpt-5.4
• Worker model: moonshot/kimi-k2.5
• Codex OAuth is valid
• Gateway is healthy
• Telegram channel is healthy
• Browser/tooling/workspace are mostly restored and working

What happens:
• Any tiny GPT-5.4 request can fail with:
• LLM request failed: DNS lookup for the provider endpoint failed.
• After repeated retries, it can turn into:
• API rate limit reached. Please try again later.

Important detail:
• This does not look like a real local DNS issue.
• On my machine:
• chatgpt.com resolves
• api.openai.com resolves
• curl can reach both
• OpenClaw logs show the provider path returning a full HTML page in rawErrorPreview, and then OpenClaw surfaces it as the DNS error.
• So it looks more like an upstream/provider/runtime failure being mislabeled as DNS.

What I already tried:
• restarted gateway multiple times
• waited for cooldown
• tested tiny prompts only
• removed Codex auth profiles manually
• re-ran:
• openclaw models auth login --provider openai-codex
• confirmed after re-auth:
• default model = openai-codex/gpt-5.4
• configured models clean
• OAuth valid again
• still same issue

limber remnantBOT Apr 14, 2026, 3:34 PM

#

devout hornetBOT Apr 14, 2026, 3:37 PM

#

Yeah, this does not smell like real DNS.

I checked the docs/source, and two things line up with your symptoms:

OpenClaw can mislabel a provider HTML error page as DNS lookup failed.
With Codex OAuth, stale models.providers.openai-codex transport overrides can shadow the built-in Codex route.

For openai-codex/gpt-5.4, the expected route is:

api: "openai-codex-responses"
base URL: https://chatgpt.com/backend-api

Not:

api: "openai-responses" / openai-completions
https://api.openai.com/v1

#

Can you paste these?

openclaw --version
openclaw doctor
openclaw config get models.providers.openai-codex
openclaw models status --json

What I’m looking for:

a Codex OAuth doctor warning
models.providers.openai-codex.api set to openai-responses or openai-completions
models.providers.openai-codex.baseUrl set to https://api.openai.com/v1
auth.unusableProfiles showing cooldown/rate-limit after the retries

If that override is present, the fix is to remove or rewrite the stale models.providers.openai-codex transport override, then restart the gateway.

#

Secondary check, on macOS/Homebrew Node, openclaw doctor also probes TLS prerequisites. If it complains about cert chain / issuer trust, the usual fix is:

brew postinstall ca-certificates

Docs:
https://docs.openclaw.ai/gateway/doctor
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/help/faq

Paste those outputs and I’ll tell you exactly which line is wrong.

boreal onyx Apr 14, 2026, 3:44 PM

#

OpenClaw 2026.4.14 issue — Codex GPT-5.4 keeps failing with fake DNS errors

Current state:

OpenClaw 2026.4.14
Default model: openai-codex/gpt-5.4
Allowed models:
- openai-codex/gpt-5.4
- moonshot/kimi-k2.5
Codex OAuth profiles are valid again after re-auth
Kimi auth is also present
Gateway / browser / Telegram all look healthy

Doctor:

models.providers.openai-codex does not exist in config
Memory search warns no embedding provider is ready, but that seems unrelated

Main symptom:

tiny GPT-5.4 prompts in UI/Telegram fail with:
- LLM request failed: DNS lookup for the provider endpoint failed
logs show rawErrorPreview returning HTML, not JSON
after retries it can turn into rate limit/cooldown

So this does not look like real local DNS.
It looks like Codex runtime/auth path is failing upstream and OpenClaw is mislabeling it as DNS.

Questions:

Is this a known 2026.4.14 Codex runtime regression?
Since models.providers.openai-codex is missing entirely, is there still any stale transport override path I should check?
Any known fix besides waiting / downgrading / staying on Kimi temporarily?

devout hornetBOT Apr 14, 2026, 3:46 PM

#

Good catch, I don’t think this is real DNS either.

From the docs/source, I can verify two things:

That DNS lookup failed copy is generic transport sanitizing, so an upstream HTML page can get mislabeled that way.
Even if models.providers.openai-codex is gone from config, stale agent models.json can still shadow it.

The big thing I’d check next is:

~/.openclaw/agents/<agentId>/agent/models.json

OpenClaw merges that file by default, and the docs explicitly say a non-empty baseUrl already in agent models.json wins over config.

So yes, there is still a stale transport path to check.

Can you run:

#

openclaw config get models.mode
rg -n '"openai-codex"|api.openai.com/v1|chatgpt.com/backend-api|openai-responses|openai-completions' ~/.openclaw/agents/*/agent/models.json

Smoking gun would be any openai-codex entry there with:

api: "openai-responses" or openai-completions
baseUrl: "https://api.openai.com/v1"

For openai-codex/gpt-5.4, the healthy route should be the Codex one on chatgpt.com/backend-api.

On your questions:

Known 2026.4.14 regression?
I can’t verify a docs/changelog-confirmed 2026.4.14-only Codex regression, but the mislabeled HTML → DNS part is believable and matches the sanitizer behavior.

#

Any stale override besides config?
Yes, agents/*/agent/models.json is the main one.
Known fix besides waiting/downgrading/Kimi?
Yes, if that file is stale: back it up, let OpenClaw regenerate it, then restart the gateway.
Also, if you want config to fully win over merged models.json state, models.mode: "replace" is the documented knob, but only if you know you don’t need persisted custom-provider state.

Short version: I would not jump to downgrade yet. I’d check models.json first. If that file is clean too, then I’d start treating this as an upstream Codex/runtime issue and keep Kimi as the temporary workaround.

Docs:
https://docs.openclaw.ai/concepts/models#models-registry-modelsjson
https://docs.openclaw.ai/gateway/doctor

If you paste the rg output, I can tell you pretty quickly whether it’s the culprit.

boreal onyx Apr 14, 2026, 3:58 PM

#

Update:

I ran the checks.

models.mode

merge

models.json grep result
From:
~/.openclaw/agents/main/agent/models.json

Matches:

line 3: "openai-codex": {
line 4: "baseUrl": "https://chatgpt.com/backend-api/v1",
line 9: "baseUrl": "https://chatgpt.com/backend-api/v1",
line 106: "api": "openai-completions",
line 124: "api": "openai-completions",

So:

I do NOT see api.openai.com/v1
I DO see chatgpt.com/backend-api/v1
but I ALSO see api: "openai-completions" in the agent models.json

Current symptom is still the same:

tiny GPT-5.4 requests can fail with:
- LLM request failed: DNS lookup for the provider endpoint failed
logs show HTML coming back in rawErrorPreview
then after retries it can hit:
- API rate limit reached. Please try again later.

What I already did:

updated to OpenClaw 2026.4.14
removed and re-added Codex OAuth
confirmed auth is valid again
gateway healthy
local DNS/network looks fine
Kimi works
issue seems specific to openai-codex/gpt-5.4

Question:

do those api: "openai-completions" lines in agents/main/agent/models.json look like the stale bad override?
should I back up and remove ~/.openclaw/agents/main/agent/models.json and let OpenClaw regenerate it?

devout hornetBOT Apr 14, 2026, 4:00 PM

#

Yes, that looks suspicious.

Two important nuances:

api: "openai-completions" is not automatically bad everywhere, because Moonshot and other OpenAI-compatible providers use it normally.
But for Codex GPT-5.4, the healthy built-in route is not that. What I’d expect is:
- api: "openai-codex-responses"
- baseUrl: "https://chatgpt.com/backend-api"

So if your openai-codex block is carrying:

baseUrl: "https://chatgpt.com/backend-api/v1" and/or
api: "openai-completions"

that does look like stale bad transport state.

Also, since your models.mode is merge, a stale agents/main/agent/models.json can absolutely keep winning.

#

So yes, my recommendation would be:

back up
~/.openclaw/agents/main/agent/models.json
move it aside rather than deleting it
restart the gateway
let OpenClaw regenerate fresh model state

I would not downgrade before trying that.

One small caution: those openai-completions lines at 106/124 are only the smoking gun if they belong to the openai-codex block. If you want to be extra sure first, paste:

sed -n '1,25p;100,130p' ~/.openclaw/agents/main/agent/models.json

If after regeneration you still get:

#

regenerated openai-codex using /backend-api/v1 or openai-completions, or
same HTML rawErrorPreview + fake DNS copy,

then I’d treat that as likely runtime/regeneration bug territory and file it here:
https://github.com/openclaw/openclaw/issues

Docs:
https://docs.openclaw.ai/concepts/models#models-registry-modelsjson
https://docs.openclaw.ai/providers/openai

If you paste that sed snippet first, I can confirm before you touch the file.

boreal onyx Apr 14, 2026, 4:10 PM

#

Update: same issue after clean re-auth and restart.

What the latest logs show:

Gateway starts normally
Browser/server starts normally
Telegram starts normally
Default model is still openai-codex/gpt-5.4

But tiny GPT-5.4 requests still fail.

Relevant log pattern:

provider = openai-codex
model = gpt-5.4
rawErrorPreview is still a full HTML page
OpenClaw then surfaces it as:
- LLM request failed: DNS lookup for the provider endpoint failed.
sometimes it first shows:
- ⚠️ API rate limit reached. Please try again later.

Examples from logs:

providerRuntimeFailureKind: rate_limit
then repeated:
- providerRuntimeFailureKind: unknown
- with HTML in rawErrorPreview

Important:

gateway is healthy
browser control is healthy
Telegram is healthy
local DNS/network was already checked and looked fine
Codex OAuth was removed and re-added cleanly
same issue remains after re-auth
models.json route was checked and looked healthy

So at this point it looks like:

Codex GPT-5.4 runtime path is still returning HTML upstream
OpenClaw is mislabeling it as DNS
retries can trigger rate limit cooldowns

Question:

does this now look like pure upstream/runtime bug territory?
anything else worth checking before treating GPT-5.4 as broken in this setup and falling back to Kimi?

devout hornetBOT Apr 14, 2026, 4:11 PM

#

Yeah, at this point I’d mostly treat it as Codex-route upstream/runtime bug territory, plus an OpenClaw error-labeling bug on top.

Why I’m saying that:

config/doctor/auth were cleaned up
gateway/channel/browser health is fine
same failure survives re-auth + restart
it is specific to openai-codex/gpt-5.4
rawErrorPreview is HTML, not a real DNS exception
retries are just pushing the profile into rate_limit / unknown cooldown buckets

Before calling it fully done, I’d only grab one last clean repro and one useful clue:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json

#

And from logs, grab the sanitized HTML title/status from rawErrorPreview if you can, for example whether it looks like:

Cloudflare / challenge
login/sign-in page
access denied
generic 5xx HTML

If that direct CLI repro also returns HTML, I would stop chasing local DNS and open a bug here:

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

Include:

openclaw --version
provider/model
that models.providers.openai-codex is absent
that models.json / doctor / re-auth looked clean

#

providerRuntimeFailureKind flipping between rate_limit and unknown
sanitized rawErrorPreview title/status
confirmation that chatgpt.com and api.openai.com resolve and curl locally

So yes, falling back to Kimi for now is reasonable.

If you need GPT-5.4 specifically right away, the direct OpenAI API route is separate from Codex OAuth, so that’s also a useful workaround/isolation path.

Docs:
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/gateway/troubleshooting

boreal onyx Apr 14, 2026, 4:15 PM

#

Better repro now:

I ran a direct CLI test, not UI/Telegram:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json

Result:

same failure
repeated 3 times in a row
all on:
- provider: openai-codex
- model: gpt-5.4

Exact output pattern:

LLM request failed: DNS lookup for the provider endpoint failed.
rawError is still HTML, not a real DNS exception

Important log context from latest run:

gateway startup is healthy
browser control is healthy
Telegram startup is healthy
webchat/models.list/node.list all work
only the actual Codex GPT-5.4 inference path fails

Earlier runtime logs also showed:

providerRuntimeFailureKind: rate_limit
then later mostly providerRuntimeFailureKind: unknown
rawErrorPreview always starts with HTML

So this is now confirmed outside UI and outside Telegram:

direct CLI infer on openai-codex/gpt-5.4 fails the same way
looks like a pure Codex runtime/upstream issue or OpenClaw Codex-route bug
not local DNS
not Telegram
not browser
not UI session state

Question:

based on this direct CLI repro, do you think this is enough to call it upstream/runtime bug territory and open a GitHub issue?
or is there one more local check worth doing first?

devout hornetBOT Apr 14, 2026, 4:16 PM

#

Yes, that’s enough.

With a direct CLI repro on:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json

and the same result every time, I’d call this bug territory now, either:

upstream Codex route returning HTML unexpectedly, or
OpenClaw’s Codex runtime/error handling misclassifying that failure as DNS.

I would not keep doing local DNS debugging at this point.

The only extra thing worth adding, if easy, is:

#

sanitized HTTP status if present
HTML <title> or first heading from rawErrorPreview

That will help distinguish:

Cloudflare/challenge
login/sign-in
access denied
generic 5xx page

But that’s optional. You already have enough to file.

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

What I’d include in the issue:

#

openclaw --version = 2026.4.14
direct CLI repro command
provider/model = openai-codex/gpt-5.4
rawError / rawErrorPreview is HTML, not a DNS exception
providerRuntimeFailureKind flips between rate_limit and unknown
gateway/browser/Telegram/UI all healthy
models.providers.openai-codex absent in config
re-auth + restart did not help
local chatgpt.com / api.openai.com DNS + curl work

I’d also stop hammering GPT-5.4 for now, since it’s just going to create more cooldown noise. Using Kimi temporarily is the sensible move.

boreal onyx Apr 14, 2026, 4:22 PM

#

Direct CLI repro is now confirmed.

Command:
openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json

Result:

fails every time
provider: openai-codex
model: gpt-5.4
output still says:
LLM request failed: DNS lookup for the provider endpoint failed.

Important detail:

rawError is HTML, not a real DNS exception
terminal shows repeated embedded run failures with:
- isError=true
- model=gpt-5.4
- provider=openai-codex
- rawError=<html> ...

CLI JSON result:
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openai-codex",
"model": "gpt-5.4",
"attempts": [],
"outputs": [
{
"text": "LLM request failed: DNS lookup for the provider endpoint failed.",
"mediaUrl": null
}
]
}

So this is now reproduced:

outside UI
outside Telegram
directly from CLI
with the same fake-DNS symptom and HTML rawError

Question:

given this direct CLI repro, is there any last local fix worth trying?
or is this now fully bug/upstream territory?
would you recommend waiting / Kimi workaround / rollback, rather than more local surgery?

devout hornetBOT Apr 14, 2026, 4:22 PM

#

At this point, I’d stop doing local surgery.

This is enough to treat as:

Codex-route bug/upstream failure for openai-codex/gpt-5.4, and
separate OpenClaw bug in how that HTML failure is being surfaced as fake DNS.

My recommendation order would be:

Open a GitHub issue now
https://github.com/openclaw/openclaw/issues
Use Kimi as the temporary workaround
Do not keep retrying GPT-5.4, because it’s just adding cooldown/rate-limit noise
Rollback only if you already know an older version worked on this same machine and you urgently need Codex back. I would not make rollback the main recommendation.

#

The only optional extra check, if easy, is grabbing the sanitized HTML <title> / status for the issue. But that’s nice-to-have, not required.

A good issue title would be:

openai-codex/gpt-5.4 direct CLI infer returns HTML rawError but surfaces as "DNS lookup failed" on 2026.4.14

So yes, short version:

not local DNS
not UI/Telegram
not worth more local debugging
file issue + use Kimi for now

If you want, I can help you tighten the GitHub issue text into a clean 5-10 line repro summary.

boreal onyx Apr 14, 2026, 4:27 PM

#

Yes please tighten the Github issue and ill post

devout hornetBOT Apr 14, 2026, 4:27 PM

#

Yep, here’s a paste-ready version.

Title
openai-codex/gpt-5.4 direct CLI infer returns HTML rawError but surfaces as "DNS lookup failed" on 2026.4.14

Body

## Version / platform

- OpenClaw: `2026.4.14`
- OS: macOS

## Summary

After updating to 2026.4.14, `openai-codex/gpt-5.4` fails even for tiny prompts.

#

The important part is that this does **not** look like a real local DNS issue:
- `chatgpt.com` resolves
- `api.openai.com` resolves
- `curl` can reach both

But OpenClaw logs show the provider path returning **HTML** in `rawError` / `rawErrorPreview`, and the user-facing error is still:

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

After repeated retries it can also turn into:
`⚠️ API rate limit reached. Please try again later.`

## Direct CLI repro

```bash
openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json

#


This reproduces the issue outside UI / Telegram.

## Actual result

- fails every time
- provider: `openai-codex`
- model: `gpt-5.4`
- CLI output still surfaces:
  `LLM request failed: DNS lookup for the provider endpoint failed.`
- terminal/runtime logs show embedded run failures with:
  - `provider=openai-codex`
  - `model=gpt-5.4`
  - `rawError=<html>...`
- runtime logs also showed:

#

  - `providerRuntimeFailureKind: rate_limit`
  - then later mostly `providerRuntimeFailureKind: unknown`
  - `rawErrorPreview` always starts with HTML

Example CLI JSON result:

```json
{
  "ok": true,
  "capability": "model.run",
  "transport": "local",
  "provider": "openai-codex",
  "model": "gpt-5.4",
  "attempts": [],
  "outputs": [
    {

#

"text": "LLM request failed: DNS lookup for the provider endpoint failed.",
"mediaUrl": null
}
]
}


## Expected result

Either:
1. the request succeeds, or
2. OpenClaw surfaces the real upstream/runtime failure

but it should **not** present an HTML provider error as a DNS lookup failure.

## What I already checked

#


- restarted gateway multiple times
- waited for cooldown
- tested tiny prompts only
- removed and re-added Codex OAuth via:
  ```bash
  openclaw models auth login --provider openai-codex

confirmed default model is still openai-codex/gpt-5.4
gateway is healthy
browser control is healthy
Telegram is healthy
webchat / models list / node list work
issue reproduces outside UI and outside Telegram
checked config and there is no models.providers.openai-codex entry

#

- checked local DNS/network separately and it looks fine

## Why this seems important

This looks like either:
- a Codex runtime/upstream failure on the `openai-codex/gpt-5.4` path, or
- an OpenClaw bug in how HTML provider failures are classified / surfaced

because the raw failure is HTML, not a DNS exception.

If you have it, I’d add one more line at the end with the sanitized HTML page title/status, but this is already strong enough to post.

boreal onyx Apr 14, 2026, 4:37 PM

#

I assigned, here is the link https://github.com/openclaw/openclaw/issues/66674

When do you think a fix will come? And whats your best suggestion to do, I want to use OpenAI as brain and Kimi as the executor, so I cant use kimi alone.

devout hornetBOT Apr 14, 2026, 4:37 PM

#

Glad you filed it.

On timing, I honestly wouldn’t guess. It could be quick if it’s just bad error handling or a small Codex-route bug, or slower if the upstream HTML response changed and the route needs deeper work.

My best practical suggestion:

If you have an OpenAI API key, switch the brain temporarily from the Codex OAuth route to the direct OpenAI API route, and keep Kimi as executor.
In other words, use openai/gpt-5.4 instead of openai-codex/gpt-5.4 until the issue is fixed.
If you only have Codex OAuth and no API key, then there isn’t a clean way to keep “OpenAI as brain” right now, because the broken piece appears to be exactly that Codex/OAuth path.
I would not do more local surgery. You’ve already done the right checks.
Rollback is only worth trying if you know an older version worked on this same machine. Otherwise I wouldn’t bet on it, because this may be route/upstream behavior rather than a purely local regression.

So the cleanest workaround is:

#

OpenAI API route for brain
Kimi stays executor

Docs:
https://docs.openclaw.ai/providers/openai

If you want, I can help you with the exact temporary config shape for “OpenAI brain + Kimi executor” without using the broken Codex OAuth path.

boreal onyx Apr 14, 2026, 4:39 PM

#

How do i get a notification that this is fixed, or a solution was found? How do I get notified

devout hornetBOT Apr 14, 2026, 4:39 PM

#

Easiest path:

Subscribe to the GitHub issue you opened
On issue #66674, click Subscribe. GitHub will notify you on replies, linked PRs, and closure.
Watch releases for the repo
On the repo page, click Watch → Custom → enable Releases (and optionally Issues if you want more noise).
Keep thread notifications on here
If someone finds a workaround in this Discord thread first, that’s the other place it’ll likely show up.

So if you want the least-effort setup: subscribe to the issue + watch releases. That’s the main combo.

boreal onyx Apr 14, 2026, 4:40 PM

#

Can i come back here and ask you if an issue has been found?

devout hornetBOT Apr 14, 2026, 4:40 PM

#

Yep, absolutely.

Come back here anytime and ask, ideally with the issue number/link again, and I can help check whether:

a fix landed,
a workaround was posted, or
the issue was closed with a specific version/commit.

That’s a totally fine way to follow up.

boreal onyx Apr 14, 2026, 5:21 PM

#

any updates?

devout hornetBOT Apr 14, 2026, 5:22 PM

#

Quick check, no fix posted yet.

Current status on #66674:

issue is still open
no maintainer reply yet
there is one additional report from another user
that second report is on Docker/Linux, so it does not look macOS-specific anymore

That’s actually useful, because it strengthens the case that this is a real openai-codex/gpt-5.4 route/runtime issue, not just your machine.

So, short version:

no solution yet
problem appears broader than macOS
Kimi / alternate OpenAI API route is still the best workaround for now

#

If you want, I can keep checking the issue when you pop back in here.

boreal onyx Apr 14, 2026, 5:57 PM

#

Can i try anything else? is there any updates

devout hornetBOT Apr 14, 2026, 5:58 PM

#

I checked again, still no real update on the issue:

still open
still no maintainer reply/fix
still just the extra Linux/Docker confirmation, which is useful because it makes this look broader than your machine

If you want to try one more thing, I’d only do it for data collection, not because I think it fixes it:

openclaw models status --probe --probe-provider openai-codex

If that probe succeeds while actual inference still fails, that strengthens the case that:

auth/probe path is okay
runtime/inference path is the broken part

#

But for practical next steps, I’d keep it simple:

Best workaround: if you have an OpenAI API key, switch the brain temporarily to the direct OpenAI API route and keep Kimi as executor.
If no API key: wait, or do a single rollback test only if an older version definitely worked on this same machine.
I would not keep poking the local setup beyond that.

So, short answer:

no meaningful issue update yet
one more probe is okay if you want more evidence
best practical path is workaround + wait, not more local surgery

boreal onyx Apr 14, 2026, 6:03 PM

#

this is what the command said

joanjanko@MacBookPro ~ % openclaw models status --probe --probe-provider openai-codex

🦞 OpenClaw 2026.4.14 (323493f) — I'm not AI-powered, I'm AI-possessed. Big difference.

│
22:02:24 [errors] Long error truncated: <html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (2): openai-codex/gpt-5.4, moonshot/kimi-k2.5

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

moonshot effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | moonshot:default=sk-juIcD...6Y6zXAEL
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:joan.janko18@gmail.com=OAuth (joan.janko18@gmail.com)

OAuth/token status

openai-codex usage: 5h 100% left ⏱4h 59m · Week 29% left ⏱3d 20h
- openai-codex:default ok expires in 7d
- openai-codex:joan.janko18@gmail.com (joan.janko18@gmail.com) ok expires in 10d

Auth probes

│ Model │ Profile │ Status │
├──────────────────────┼──────────────────────────────────────────────────────────────────────┼────────────┤
│ openai-codex/gpt-5.4 │ openai-codex:default (oauth) │ ok · 16.4s │
│ openai-codex/gpt-5.4 │ openai-codex:joan.janko18@gmail.com (joan.janko18@gmail.com) (oauth) │ ok · 15.7s │

devout hornetBOT Apr 14, 2026, 6:03 PM

#

That’s actually a really useful data point.

What it tells us:

both Codex OAuth profiles probe ok
usage/quota metadata is being read
so auth itself is not the broken piece
but OpenClaw is still printing:
- Long error truncated: <html>...

So the picture now is:

OAuth/profile resolution looks healthy
probe path looks healthy
runtime/inference path is still the part failing
and the HTML response is still leaking into error handling

#

That makes this look even less like local DNS, and even less like “bad login”.

So my take now:

no real issue update yet
this output strengthens the bug report
I would not keep changing local config

Best next move: add this exact probe result as a comment on #66674, especially:

both openai-codex/gpt-5.4 auth probes are ok
the command still prints Long error truncated: <html>...

That’s a very strong clue for whoever debugs it.

Practical recommendation stays the same:

#

use the workaround for now
stop local surgery
wait for issue movement / fix

If you want, I can help you turn this probe output into a short follow-up comment for the GitHub issue too.

boreal onyx Apr 14, 2026, 6:04 PM

#

yes do so please

devout hornetBOT Apr 14, 2026, 6:05 PM

#

Yep, paste this as a follow-up comment:

Additional data point from `models status --probe`:

```sh
openclaw models status --probe --probe-provider openai-codex

Result:

both openai-codex/gpt-5.4 OAuth profiles probe as ok
usage/quota metadata also loads
but the command still emits:

[errors] Long error truncated: <html> ...

#


Probe table showed both profiles succeeding for `openai-codex/gpt-5.4`, while actual inference still fails.

This seems to narrow the problem further:

- OAuth/profile resolution looks healthy
- provider probe path looks healthy
- actual runtime/inference path is still the part failing
- HTML is still being returned somewhere in the Codex path and later surfaced as fake DNS

So this continues to look like a runtime/Codex-route bug rather than bad local DNS or a bad OAuth login.

If you want, after you post it, I can check the issue again and tell you if the thread got more actionable.

boreal onyx Apr 14, 2026, 6:07 PM

#

posted, hopefully we can have some issue, is there any terminal things i can try or i tried enough

devout hornetBOT Apr 14, 2026, 6:07 PM

#

Honestly, I think you’ve tried enough.

At this point, more terminal debugging is unlikely to teach you much more unless you’re doing it to:

test a workaround, or
help maintainers with extra evidence

So I’d split it like this:

Worth trying

If you have an OpenAI API key: test the direct OpenAI route as the brain, instead of Codex OAuth
If an older OpenClaw version definitely worked on this same machine: do one rollback test

Not really worth doing more of

more re-auths
more gateway restarts
more tiny prompt retries

#

more local DNS poking

You’ve already established the important part:

auth probe looks healthy
runtime infer is broken
raw error is HTML
fake DNS message is secondary/misleading

So yes, I’d shift from debugging to workaround mode now.

If you want, I can help you with the cleanest temporary setup for:
OpenAI as brain + Kimi as executor, without using the broken Codex OAuth path.

boreal onyx Apr 14, 2026, 7:07 PM

#

Any updates?

devout hornetBOT Apr 14, 2026, 7:08 PM

#

I checked again, still no new movement.

Right now it still looks like:

no maintainer response yet
no posted fix/workaround yet
the main extra signal is still the Docker/Linux confirmation, which helps show it’s not just your Mac

So, unfortunately: no real update yet.

Best move is still:

keep the issue subscribed
use the workaround path for now
check back later and I can re-scan it with you again

boreal onyx Apr 14, 2026, 7:56 PM

#

Anything new? that could match with my issue and could help out, or anything i could try? and also give me what is the proper issue that we have

devout hornetBOT Apr 14, 2026, 7:57 PM

#

I found something that matches your case really closely.

The best match right now is:

#66633
openai-codex provider fails with Cloudflare 403 on every request after upgrade from 2026.4.12 → 2026.4.14

And there’s also an older related one:

#62142
openai-codex provider fails with Cloudflare 403 on headless HTTP after upgrade to 2026.4.5
(closed, looks like an older version of the same family)

Why this matches your issue

#66633 lines up almost exactly with what you’re seeing:

#

openai-codex/gpt-5.4
HTML coming back instead of API JSON
first rate_limit, then fake DNS lookup failed
problem appears after upgrade
likely Cloudflare challenge / bot-mitigation on the Codex route, not real DNS

So the proper issue family now looks like:

Codex route is getting Cloudflare HTML / challenge responses, and OpenClaw is misclassifying that as DNS or rate-limit.

Your issue #66674 is still useful, especially because it has the clean direct CLI repro and the probe-vs-runtime split. But the likely root cause now looks closer to #66633 / #62142 than to “mystery local DNS”.

One safe extra thing you can try

If you want one more non-invasive check, try:

#

curl -sI https://chatgpt.com/backend-api/v1

If that comes back with something like:

HTTP/2 403
cf-mitigated: challenge

that would match #66633 very strongly.

My honest take

No fix posted yet
Best current match: #66633
Your current issue: still valid, but probably same root-cause family
Best practical move: workaround mode, not more local surgery

#

If you want, I can help you write one short comment on #66674 saying “this now appears to match #66633 / #62142 closely”.

boreal onyx Apr 14, 2026, 9:14 PM

#

I checked:

curl -sI https://chatgpt.com/backend-api/v1

Result:

HTTP/2 403
content-type: text/html; charset=UTF-8
cf-mitigated: challenge
server: cloudflare
cf-ray: 9ec5ab25af668a0d-DXB

So hitting the Codex base URL directly returns a Cloudflare challenge HTML page, not JSON.
That seems consistent with the rawError/rawErrorPreview HTML we were seeing.

devout hornetBOT Apr 14, 2026, 9:14 PM

#

Yep, that’s basically the smoking gun.

That result means:

the Codex base URL is reachable
but Cloudflare is serving a challenge HTML page
so the failure is not DNS
and it matches #66633 very closely

So the proper issue now looks like:

openai-codex route is getting Cloudflare 403 challenge HTML on chatgpt.com/backend-api/v1, and OpenClaw is then misclassifying that as DNS / rate-limit.

At this point I would consider the diagnosis pretty solid.

What I’d do now

#

Stop local troubleshooting
Use workaround mode
Add this curl result to your issue
Mention that it appears to match #66633 closely

If you want, paste this as a short comment:

Additional confirmation:

```sh
curl -sI https://chatgpt.com/backend-api/v1

returns:

#

- `HTTP/2 403`
- `content-type: text/html; charset=UTF-8`
- `cf-mitigated: challenge`
- `server: cloudflare`

This matches the HTML seen in `rawError` / `rawErrorPreview` and makes it look much more like a Cloudflare challenge on the Codex route than a real DNS failure.

This appears to match #66633 very closely.

So yeah, I think you’ve got the root cause pinned down as far as end-user debugging can reasonably go.

boreal onyx Apr 14, 2026, 9:43 PM

#

how can i check that it is fixed? maybe its a openai issue, can you find the same issue in others and see if they found any fix? did the 66633 find any fixing, can i do anything to fix it on my side

devout hornetBOT Apr 14, 2026, 9:44 PM

#

Yes, there’s finally something useful.

I checked #66633, and there is now a user-reported workaround that was confirmed by another user.

What people found

Rollback did not fix it
Nuking the OpenClaw directory did not fix it
A workaround that did work was adding an explicit openai-codex transport mapping in config

This is the reported 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"
          }
        ]
      }
    }
  }
}

What this suggests

#

This makes it look less like a pure OpenAI outage and more like:

Cloudflare is challenging one Codex route/path, and
forcing the explicit openai-codex-responses transport avoids the broken path/selection

So the issue now looks closer to:

OpenClaw Codex transport/path regression, which then hits Cloudflare challenge HTML and gets misreported as DNS/rate-limit.

If you want to try it

I’d do it as a careful workaround:

back up your ~/.openclaw/openclaw.json
add that config block
restart the gateway
test with:

#

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json

How to know it’s fixed

You’re fixed if:

that infer command returns a normal reply
no more LLM request failed: DNS lookup for the provider endpoint failed.
no more HTML rawError / rawErrorPreview

What is the “proper issue” now?

The best root-cause match is still:

#66633 - Cloudflare 403 / Codex route regression

Your issue #66674 is still useful, but #66633 now looks like the main issue family.

#

If you want, I can help you turn that workaround into the exact json5 snippet for your current config so you can paste it safely.

boreal onyx Apr 14, 2026, 9:57 PM

#

It worked.

What fixed it:
I added an explicit openai-codex transport block in ~/.openclaw/openclaw.json:

{
"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
openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json

Now it returns a normal reply instead of HTML/fake DNS.

So the fix appears to be:

explicit Codex transport mapping
forcing openai-codex-responses + https://chatgpt.com/backend-api

This really does look like stale/bad transport selection was the cause.

devout hornetBOT Apr 14, 2026, 9:58 PM

#

Nice, glad you got it working 🎉

That really does point to a transport-selection regression, not bad DNS or bad OAuth.

I’d do two quick follow-ups:

Comment the working workaround on the GitHub issue(s), especially #66674 and ideally #66633 too, so others can find it fast.
If this fixed it here, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

I’d keep that explicit openai-codex block in place until there’s an official fix/release note saying it’s no longer needed.

Glad that helped! 🦐

boreal onyx Apr 14, 2026, 9:59 PM

#

can you help me doing the comment please, and help me on the steps what i should do to end this, thank you so much

devout hornetBOT Apr 14, 2026, 10:00 PM

#

Yep, here’s the easiest way to wrap it up cleanly.

Paste this comment on the GitHub issue

You can post this on #66674, and also on #66633 if you want:

Workaround confirmed on my side.

What fixed it was adding an explicit `openai-codex` transport block in `~/.openclaw/openclaw.json`:

```json
{
  "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 I ran:

```bash

#

openclaw gateway restart
openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json


After that, `openai-codex/gpt-5.4` returned a normal reply again instead of HTML / `DNS lookup failed`.

This appears to confirm that the issue is not real DNS, but bad/stale Codex transport selection, and that forcing:

- `api: "openai-codex-responses"`
- `baseUrl: "https://chatgpt.com/backend-api"`

works around it.

Then do these steps

Post that comment on the issue

#

Keep that config block in your ~/.openclaw/openclaw.json for now
Leave the GitHub issue subscribed so you see when there’s an official fix
Right-click the solution message here → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow
Don’t remove the workaround yet until an official fix lands and someone confirms it’s safe to delete

Optional cleanup later

When the issue is officially fixed, test by:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "hi" --json

If it still works without the override, then you can remove the config workaround.

You did the hard part already. This is basically the finish line.

boreal onyx Apr 14, 2026, 10:04 PM

#

the app is not responding now but it is fixed, do i tell my openclaw to fix anything or clean anything just so i am organized?

devout hornetBOT Apr 14, 2026, 10:04 PM

#

If it’s fixed, I’d keep cleanup minimal.

What I’d do to stay organized:

Keep the workaround block in ~/.openclaw/openclaw.json
Don’t remove it yet.
Add a short comment above it so future-you knows why it’s there, for example:

// Temporary workaround for openai-codex Cloudflare/DNS misrouting
// See: #66633 and #66674

Keep a backup of your config once it’s working.
Do not nuke or “clean” auth/state right now

#

You’ve got a working setup, so I wouldn’t touch profiles, sessions, or models files unless something breaks again.

Only after an official fix lands, test without the override and then remove it.

If the app itself is not responding right now, I’d only do one simple thing:

restart the gateway once more

and if it’s just the UI, refresh/reopen it.

So short version:
no major cleanup, no surgery, just keep the workaround, label it clearly, and leave the rest alone.

boreal onyx Apr 14, 2026, 10:08 PM

#

do i have to do anything else here?

#Codex GPT-5.4 returning fake “DNS lookup failed” after 2026.4.14 update

Worth trying

Not really worth doing more of

Why this matches your issue

One safe extra thing you can try

My honest take

What I’d do now

What people found

What this suggests

If you want to try it

How to know it’s fixed

What is the “proper issue” now?

Paste this comment on the GitHub issue

Then do these steps

Optional cleanup later