openai-codex endpoint not resolving any models | Friends of the Crustacean 🦞🤝 | Page 1

median crystal Apr 15, 2026, 12:28 PM

#

I'm seeing a recent trend with various help tickets open reporting their setup stopped working. I noticed in the most recent you suggested that there's only one active endpoint now. Trying to use it but it's not workign for me

⚠️ Agent failed before reply: Unknown model: openai-codex/gpt-5.4. Check gateway logs for details.

lucid crystalBOT Apr 15, 2026, 12:30 PM

#

That error usually means the gateway did not load the Codex provider/auth, not that openai-codex/gpt-5.4 disappeared.

Current docs still say:

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

Can you paste these from the same machine that runs the gateway?

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

If openai-codex comes back empty, or status shows missing/expired auth, try:

#

pnpm openclaw models auth login --provider openai-codex
pnpm openclaw gateway restart

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/concepts/models

So yeah, I don’t think this is “that endpoint is gone”. From the current docs/source, openai-codex/gpt-5.4 is still the right Codex OAuth route. I’m more suspicious of version drift or auth not being visible on the gateway host.

median crystal Apr 15, 2026, 12:40 PM

#

oot@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851/clawdbot node dist/entry.js models list --provider openai-codex

🦞 Clawdbot 2026.1.21-2 (80c1edc) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

Model Input Ctx Local Auth Tags
openai-codex/gpt-5.4 - - - - default,configured,missing

root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851/clawdbot node dist/entry.js models auth login --provider openai-codex

🦞 Clawdbot 2026.1.21-2 (80c1edc) — Meta wishes they shipped this fast.

│
◆ Select a provider
│ ● Qwen (Docs: /providers/qwen)

lucid crystalBOT Apr 15, 2026, 12:42 PM

#

Yep, that output is the smoking gun.

openai-codex/gpt-5.4 is there, but it is marked missing. So this is not “the endpoint is gone”, it is “the gateway has no usable Codex auth loaded”.

Also, you’re on 2026.1.21-2, which is pretty old. On current builds, models auth login --provider openai-codex is a normal supported flow, so it dumping you into a generic provider picker is another sign you’re fighting an old install.

I’d do this in order:

Update first
Re-run Codex auth on the gateway host
Restart the gateway

Docs:
https://docs.openclaw.ai/install/updating
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/help/faq

#

If you have a normal CLI install, the flow is:

pnpm openclaw update
pnpm openclaw models auth login --provider openai-codex
pnpm openclaw gateway restart

If you’re running from a source checkout instead of an installed CLI, update that checkout + rebuild first, then run the auth login again.

Important detail: if you only have ChatGPT/Codex sign-in, stay on openai-codex/gpt-5.4. openai/gpt-5.4 is the separate API-key route.

If you update and it still throws you into Qwen / still shows missing, paste:

pnpm openclaw models status --probe

#

and I’ll help you narrow it down.

median crystal Apr 15, 2026, 12:48 PM

#

wait hold on that's bad advice, like the root issue is im trying to run auth login on the provider and it's not showing it in the list, like it's not available, but i only see qwen instead, doesn't th at mean that it's defaulting to the non-merge option so i have to do something like models.mode = "merge" or models.providers.mode = "merge" can you offer my clarity? what im saying is bc i have it set to qwen it's treating it like thats the only provider i have bc it defaults to a non-merge mode

lucid crystalBOT Apr 15, 2026, 12:50 PM

#

You’re right to push back, I mixed “auth is missing” with “why the login picker isn’t offering the provider.”

The clear answer:

The real key is models.mode
models.providers.mode is not a valid key
Per current docs, the default is already merge
Only models.mode: "replace" switches you into “configured providers only”

Docs/source on that:

So the first check is:

#

pnpm openclaw config get models.mode

Interpretation:

If it says replace: yes, your theory is plausible. A Qwen-only config can hide built-ins from the active provider catalog. In that case, switch it back to merge.
If it says merge or is unset: then no, this is not a merge-mode problem.

One important clue though: your earlier models list --provider openai-codex did resolve openai-codex/gpt-5.4 and marked it missing. That means the model/provider ref is at least being seen by the catalog layer. So this does not look like a clean “OpenAI Codex is completely absent because of replace mode” case.

That’s why I’m more suspicious of this combo:

old build (2026.1.21-2)
auth/login picker behavior on that build
missing Codex auth on top of that

#

Also, on current source, models auth login --provider openai-codex explicitly targets the requested provider. So if your build ignores that and still dumps you into a generic picker with just Qwen, that strongly smells like old-version behavior, not just merge mode.

If you paste the output of:

pnpm openclaw config get models.mode

I can tell you pretty quickly which branch you’re in.

median crystal Apr 15, 2026, 1:54 PM

#

ok so i updated to the latest version now i get a new error

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

13:39:50 [plugins] embedded acpx runtime backend ready
13:40:33 [tools] agents.jesse.tools.allow allowlist contains unknown entries (group:clawdbot). These entries won't match any tool unless the plugin is enabled.
13:40:41 [agent/embedded] embedded run agent end: runId=43dcb0a0-753a-401c-90a2-bc0ec3cc1bc5 isError=true model=gpt-5.4 provider=openai-codex error=LLM request failed: DNS lookup for the provider endpoint failed. rawError=<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-direction…
13:40:50 [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
13:40:50 [agent/embedded] embedded run agent end: runId=43dcb0a0-753a-401c-90a2-bc0ec3cc1bc5 isError=true model=gpt-5.4 provider=openai-codex error=<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-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… rawError=<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-direction…
13:41:01 [errors] Long error truncated: <html>

#

openclaw models status

🦞 OpenClaw 2026.4.14 (323493f) — If something's on fire, I can't extinguish it—but I can write a beautiful postmortem.

Config : ~/.clawdbot/clawdbot.json
Agent dir : ~/.clawdbot/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): openai-codex/gpt-5.4

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

openai-codex effective=profiles:~/.clawdbot/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth
qwen-portal effective=profiles:~/.clawdbot/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | qwen-portal:default=OAuth

OAuth/token status

openai-codex usage: 5h 100% left ⏱4h 59m · Week 91% left ⏱1d 3h
- openai-codex:default ok expires in 41h
qwen-portal
- qwen-portal:default ok expires in 4h

lucid crystalBOT Apr 15, 2026, 1:55 PM

#

That’s actually progress. You’re past the Unknown model problem now.

The new failure is a network/DNS problem on the gateway host, not a model-catalog problem.

A couple quick clarifications:

provider=openai-codex model=gpt-5.4 in the log means it is selecting Codex now.
The group:clawdbot warning is unrelated. That’s just a stale tools.allow entry.

For Codex OAuth, the native endpoint is chatgpt.com/backend-api, so this new error usually means one of these:

you have a custom models.providers.openai-codex.baseUrl / proxy override pointing somewhere bad
the VPS cannot properly resolve or reach chatgpt.com
something in front of it is returning an HTML block/error page instead of the upstream response

Can you paste these next:

#

pnpm openclaw models status --probe
pnpm openclaw config get models.providers.openai-codex.baseUrl

If you’re still running from the source checkout, use the equivalent node dist/entry.js ... form.

If baseUrl is set to something custom, that’s the first thing I’d fix.
If baseUrl is empty/default, then this is host DNS/egress, so also check:

getent hosts chatgpt.com
curl -I https://chatgpt.com

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

#

https://docs.openclaw.ai/gateway/troubleshooting

One extra cleanup item for later: group:clawdbot in tools.allow is obsolete. Valid allowlist entries are real tool names/groups like group:messaging. Not the cause here, though.

#

Nice, this narrows it down a lot.

Your auth looks healthy now. In fact, models status is already showing Codex usage windows, which means the gateway can talk to the Codex usage endpoint at least well enough to read account info.

So this is not the old missing-model / missing-auth problem anymore.

What I’m suspicious of now:

a custom openai-codex.baseUrl / proxy override
a transport-specific failure during generation
an HTML block/error page from something in front of the real endpoint

Can you paste these next:

openclaw config get models.providers.openai-codex.baseUrl

#

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

Why those matter:

if baseUrl is set to something custom, that is the first thing I’d undo
if the live probe fails too, we’ll get a much cleaner read on whether this is endpoint/transport/proxy related

One extra thought: since Codex is WebSocket-first with SSE fallback, if the probe/baseUrl look normal, I’d test forcing SSE temporarily:

{
  agents: {
    defaults: {
      models: {

#

        "openai-codex/gpt-5.4": {
          params: { transport: "sse" }
        }
      }
    }
  }
}

If that suddenly works, then the problem is probably in the WS path, not the auth itself.

Also, the raw error being HTML is weird, and usually points to a proxy / WAF / block page rather than a normal API failure.

Docs:
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/concepts/model-providers

#

https://docs.openclaw.ai/cli/models

median crystal Apr 15, 2026, 1:58 PM

#

openclaw models status --probe

🦞 OpenClaw 2026.4.14 (323493f) — Finally, a use for that always-on Mac Mini under your desk.

│
13:56:31 [tools] agents.main.tools.allow allowlist contains unknown entries (group:clawdbot). These entries won't match any tool unless the plugin is enabled.
◇
Config : ~/.clawdbot/clawdbot.json
Agent dir : ~/.clawdbot/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): openai-codex/gpt-5.4

Auth overview
Auth store : ~/.clawdbot/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (2): openai-codex (1), qwen-portal (1)
openai-codex effective=profiles:~/.clawdbot/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth
qwen-portal effective=profiles:~/.clawdbot/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | qwen-portal:default=OAuth

OAuth/token status
openai-codex usage: 5h 100% left ⏱4h 59m · Week 91% left ⏱1d 2h
openai-codex:default ok expires in 41h
qwen-portal
qwen-portal:default ok expires in 4h

Auth probes
┌─────────────────────────┬──────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├─────────────────────────┼──────────────────────────────┼────────────┤
│ openai-codex/gpt-5.4 │ openai-codex:default (oauth) │ ok · 22.4s │
│ qwen-portal/coder-model │ qwen-portal:default (oauth) │ ok · 13.9s │
└─────────────────────────┴──────────────────────────────┴────────────┘
Probed 2 targets in 43.4s
root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851 openclaw config get models.providers.openai-codex.baseUrl

🦞 OpenClaw 2026.4.14 (323493f) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

Config path not found: models.providers.openai-codex.baseUrl

#

root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851 openclaw models status --probe --probe-provider openai-codex

🦞 OpenClaw 2026.4.14 (323493f) — Your config is valid, your assumptions are not.

│
13:58:16 [tools] agents.main.tools.allow allowlist contains unknown entries (group:clawdbot). These entries won't match any tool unless the plugin is enabled.
◇
Config : ~/.clawdbot/clawdbot.json
Agent dir : ~/.clawdbot/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): openai-codex/gpt-5.4

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

openai-codex effective=profiles:~/.clawdbot/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth
qwen-portal effective=profiles:~/.clawdbot/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | qwen-portal:default=OAuth

OAuth/token status

openai-codex usage: 5h 100% left ⏱4h 59m · Week 91% left ⏱1d 2h
- openai-codex:default ok expires in 41h
qwen-portal
- qwen-portal:default ok expires in 4h

Auth probes
┌──────────────────────┬──────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├──────────────────────┼──────────────────────────────┼────────────┤
│ openai-codex/gpt-5.4 │ openai-codex:default (oauth) │ ok · 18.8s │
└──────────────────────┴──────────────────────────────┴────────────┘
Probed 1 target in 40.3s

lucid crystalBOT Apr 15, 2026, 2:00 PM

#

This is really helpful, and it changes the diagnosis.

models status --probe is ok
models.providers.openai-codex.baseUrl is not set, which is normal
your OAuth profile is healthy
usage lookup is working

So I don’t think this is a real DNS problem anymore. The DNS lookup... text looks like a misleading wrapper around the raw HTML interruption page you saw in the logs.

In other words, provider setup looks fine now. The failure is likely in the actual run transport/path, not auth/catalog/config.

The next thing I’d try is forcing SSE for Codex instead of the default auto transport:

{
  agents: {

#

    defaults: {
      models: {
        "openai-codex/gpt-5.4": {
          params: { transport: "sse" }
        }
      }
    }
  }
}

Then restart the gateway and retry.

Why I’m suggesting that: current docs/source say Codex is WebSocket-first with SSE fallback, and your probe succeeding makes me think the normal request path is basically fine, but the run path may be tripping over the WS side or hitting one of Codex’s weird HTML interruption pages.

Docs:

#

https://docs.openclaw.ai/concepts/model-providers
https://docs.openclaw.ai/providers/openai

If SSE still fails, can you paste just the HTML page title / first line or two from the raw error? Not the whole blob, just enough to identify whether it’s a “try again”, block page, or something else.

And yeah, that group:clawdbot warning is still unrelated.

#

Perfect, that’s the split I wanted.

At this point we know:

Codex auth is good
live probe is good
no custom openai-codex.baseUrl override
but normal agent runs still fail

So this has stopped looking like user config, and started looking like a run-path bug / transport issue.

The next clean isolation step is a minimal real inference call outside the normal agent turn:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json

#

If that works, but normal chat/agent turns still fail, then the problem is very likely in the agent run path itself, for example WS path, tool payload, or full prompt shape.

If that fails too, paste the error and we’ll know the failure is below the agent layer.

I’d still test the SSE override too:

{
  agents: {
    defaults: {
      models: {
        "openai-codex/gpt-5.4": {
          params: { transport: "sse" }
        }
      }
    }

#

}
}

Why I’m leaning this way now: probe success + agent failure is exactly the kind of pattern where a model is fine, but the full run path is not.

Infer docs:
https://docs.openclaw.ai/cli/infer

If infer model run passes and the normal run still dies with that HTML blob, I’d honestly treat that as GitHub issue territory.

median crystal Apr 15, 2026, 2:04 PM

#

so i ran this

root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851 openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json

{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openai-codex",
"model": "gpt-5.4",
"attempts": [],
"outputs": [
{
"text": "⚠️ API rate limit reached. Please try again later.",
"mediaUrl": null
}
]
}

getent hosts chatgpt.com
2a06:98c1:3100::6812:202f chatgpt.com
2a06:98c1:310b::ac40:9bd1 chatgpt.com

lucid crystalBOT Apr 15, 2026, 2:05 PM

#

Yep, that’s the smoking gun.

infer model run worked end-to-end and came back with:

⚠️ API rate limit reached. Please try again later.

So this is not actually a DNS problem anymore.

What that proves:

OpenClaw can resolve chatgpt.com
your openai-codex auth is valid
the provider call succeeds far enough to return a real model-side result

So the earlier DNS lookup for the provider endpoint failed message is basically a misleading wrapper, probably around one of Codex’s weird HTML interruption / throttling responses.

Also, getent only showing IPv6 is not the root issue here, because the real Codex call already completed.

#

Bottom line

This is now a Codex OAuth rate-limit / interruption issue, not a config issue.

What I’d do next

Wait a bit and retry
Avoid concurrent/repeated runs for a while
Optionally force transport: "sse" to reduce WS weirdness, but that will not bypass a real rate limit
Use a temporary fallback model/provider so the agent can keep replying when Codex is throttled

And honestly, with the current evidence, I’d call the bad DNS/HTML surfacing a bug. Please file it here with the outputs you collected:

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

If you want, I can help you write the exact issue body from what you already gathered.

median crystal Apr 15, 2026, 3:28 PM

#

root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851 openclaw config set models.providers.openai-codex '{"baseUrl":"https://chatgpt.com/backend-api/codex","api":"openai-codex-responses","models":[{"id":"gpt-5.4","name":"GPT-5.4"}]}' --json
Updated models.providers.openai-codex. Restart the gateway to apply.
root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851 openclaw config set models.mode replace

🦞 OpenClaw 2026.4.14 (323493f) — iMessage green bubble energy, but for everyone.

Config overwrite: /root/.openclaw/openclaw.json (sha256 cb5c19747f74caa54d4a441f6d5e95828c097389511fea576918238b539a996c -> cea176d5f848ee9d196001fd4e5e58967459f8eaee8248b5f9eb523f07eb28de, backup=/root/.openclaw/openclaw.json.bak)
Updated models.mode. Restart the gateway to apply.
root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851 openclaw gateway restart

🦞 OpenClaw 2026.4.14 (323493f) — If you can describe it, I can probably automate it—or at least make it funnier.

Restarted systemd service: openclaw-gateway.service
root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851 openclaw models list --provider openai-codex

🦞 OpenClaw 2026.4.14 (323493f) — I read logs so you can keep pretending you don't have to.

Model Input Ctx Local Auth Tags
openai-codex/gpt-5.4 text 195k no yes default,configured
root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851
root@ubuntu-4gb-nbg1-2:/mnt/HC_Volume_100393851 openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openai-codex",
"model": "gpt-5.4",
"attempts": [],
"outputs": [
{
"text": "smoke-ok",
"mediaUrl": null
}
]
}
-- this is the confirmed fix per another thread with another user that found the workaround for now

#openai-codex endpoint not resolving any models

Bottom line

What I’d do next