#After updating to 4.14, Codex OAuth stopped working — getting DNS lookup failures on gpt-5.3-codex.

58 messages · Page 1 of 1 (latest)

meager pilot
#

using Open.Ai chatgpt plus subscription for model. Everything was working then upgraded to openclaw 4.14 and started having issues with agent not being able to respond and getting dns errors... tried rolling back to 4.12 and still same issue. Checked and my open.AI codex is not over limit..

molten rockBOT
#

Let me check the actual docs and auth notes before I steer you wrong.

#

I found one potentially relevant thing: newer releases warn if you still have old models.providers.openai-codex transport overrides, because they can shadow the built-in Codex OAuth path and break fallback behavior. Let me confirm the exact knobs before I send you a fix.

#

If the error is ENOTFOUND / EAI_AGAIN / getaddrinfo, that points to DNS/network, not quota, so checking Codex usage was good but it’s probably not the root cause.

Also, because it still happens after rolling back, I’m suspicious this is state/config, not the 4.14 binary itself.

Can you paste these first:

openclaw --version
openclaw status --all
openclaw models status
openclaw doctor --deep

A few specific things to check:

  1. Make sure you’re using openai-codex/*, not openai/*
    ChatGPT Plus / Codex OAuth in OpenClaw is the openai-codex route, not direct OpenAI API.
#

  1. Look for stale models.providers.openai-codex overrides
    Newer docs call out that old manual models.providers.openai-codex transport settings can shadow the built-in Codex OAuth path and break fallback behavior, even after downgrade. openclaw doctor should warn about this.

  2. TLS/DNS to OpenAI
    openclaw doctor --deep also checks Codex OAuth TLS prerequisites. If Node/OpenSSL can’t validate or resolve OpenAI endpoints, you’ll get failures before the agent can respond.

If you can, also paste the exact log line from:

openclaw logs --follow

Docs:

#

Paste those outputs and I’ll help narrow it down.

meager pilot
#

OpenClaw 2026.4.12 (1c0672b)

OpenClaw status --all

Overview
Version : 2026.4.12
OS : linux 6.8.0-107-generic (x64)
Node : 22.22.2
Config : ~/.openclaw/openclaw.json
Dashboard : http://127.0.0.1:18789/
Tailscale : off
Channel : stable (default)
Update : pnpm · npm update 2026.4.14
Gateway : local · ws://127.0.0.1:18789 (local loopback) · reachable 37ms · auth token · [REDACTED] (172.16.1.2) app 2026.4.12 linux 6.8.0-107-generic
Gateway service : systemd not installed
Node service : systemd not installed
Agents : 1 total · 1 bootstrapping · 1 active · 3 sessions
Secrets : none

Agents
main | PRESENT | 3 sessions | 4m ago | ~/.openclaw/agents/main/sessions/sessions.json

Diagnosis
✓ Config: /data/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
✓ Port 18789
! Tailscale: off · unknown
✓ Skills: 14 eligible · 0 missing · /data/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)
Gateway health: reachable 37ms

openclaw models status

Default : nexos/80c8f8ab-a173-407f-a4b7-74fcdee2525c (from Nexos Gpt 5 2)
Fallbacks (0) : -

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

  • nexos: profiles=1 (oauth=0, token=0, api_key=1) | source=models.json
  • openai-codex: profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:[REDACTED]=OAuth

Missing auth

  • openai: no API key configured

OAuth/token status

  • openai-codex usage: 5h 100% left · Week 73% left
    • openai-codex:[REDACTED] ok expires in 10d

openclaw doctor --deep

Update: not a git checkout, installed via npm
Gateway: was unset, fixed with openclaw config set gateway.mode local, now reachable
Plugin warning: oxylabs-ai-studio-openclaw suspicious ownership (uid=1000, expected uid=0 or root)
Memory search: enabled but no embedding provider configured
Skills: 14 eligible, 44 missing requirements
Plugins: 55 loaded, 43 disabled, 0 errors
Orphan transcripts: 7 files not referenced by sessions.json

ISSUE: ChatGPT Plus OAuth (openai-codex) was working on 4.12 before auto-update to 4.14 broke it. Rolled back to 4.12, still broken. Auth is valid, quota is healthy (100% daily / 73% weekly), but getting "API rate limit reached" banner and empty response bubbles on all openai-codex models. Default model keeps reverting to Nexos after every gateway restart even after running openclaw models set openai-codex/gpt-5.4. Running in Docker container on Hostinger VPS. gateway.mode was unset — just fixed. DNS errors in logs pointing to provider endpoint failures intermittently.

molten rockBOT
#

I’m checking one thing before I answer: whether openclaw models set is supposed to persist across restarts or if you need to set agents.defaults.model.primary in config instead. That “reverts to Nexos” detail matters.

#

That helps a lot. I don’t think this is your ChatGPT Plus quota itself.

What it looks like now:

  1. Codex auth is healthy
    Your openai-codex OAuth profile is valid and quota looks fine.

  2. Your gateway is probably failing to resolve/reach the Codex endpoint from inside Docker
    OpenClaw’s Codex OAuth path talks to chatgpt.com/backend-api, so intermittent DNS failures there would break replies even with healthy auth.

  3. The “reverting to Nexos” part may actually be fallback, not a real reset
    Docs say if the configured default model can’t be resolved/exposed, OpenClaw falls back to the first configured provider/model. So models status showing Nexos does not prove the config got overwritten.

Can you run these next:

# 
openclaw config get agents.defaults.model.primary
openclaw config get models.providers.openai-codex --json
openclaw models status --probe --probe-provider openai-codex
openclaw models status --json

What I’m looking for:

  • If agents.defaults.model.primary is already openai-codex/gpt-5.4, but models status still resolves Nexos, then Codex is failing and OpenClaw is just falling back.
  • If models.providers.openai-codex is populated, that’s suspicious. The docs specifically warn that old overrides there can shadow the built-in Codex OAuth path.
  • If models status --json shows auth.unusableProfiles for openai-codex, that would explain the fake-looking “API rate limit reached” banner even while quota still shows healthy.

If you are not intentionally proxying Codex, and models.providers.openai-codex has old transport settings, I’d try:

# 
openclaw config unset models.providers.openai-codex
openclaw config set agents.defaults.model.primary "openai-codex/gpt-5.4"

Then restart the gateway and re-check openclaw models status.

Since you’re on Docker/VPS, I’d also test DNS inside the container:

getent hosts chatgpt.com auth.openai.com

If that fails or is flaky, this is probably a container/host DNS issue, not an OpenClaw auth issue.

Docs:

meager pilot
#

Results from requested commands:
agents.defaults.model.primary:
openai-codex/gpt-5.4
models.providers.openai-codex:
Config path not found: models.providers.openai-codex
(no stale overrides — clean)
models status --probe:
openai-codex/gpt-5.4 | OAuth ([REDACTED]) | ok · 11.1s
Auth probe passed — token is valid and reachable.
models status --json (key fields):
defaultModel: openai-codex/gpt-5.4
resolvedDefault: openai-codex/gpt-5.4
unusableProfiles: []
openai-codex OAuth status: ok, expires in 10d
getent hosts chatgpt.com auth.openai.com:
chatgpt.com resolves (IPv6: 2a06:98c1:...)
auth.openai.com resolves (IPv6: 2a06:98c1:...)
DNS resolves fine — IPv6 addresses returned.
Summary for you: Config is correct, auth probe passed at 11.1s, DNS resolves. But the live agent still gets DNS failures and rate limit errors when actually making requests. Suspect the issue may be IPv6-only resolution inside the Docker container — chatgpt.com and auth.openai.com are only returning IPv6 addresses, but the container may not have IPv6 connectivity working properly.

molten rockBOT
#

Nice, that narrows it a lot. I’m checking the exact OpenClaw config path for forcing IPv4-first on model-provider requests so I don’t hand you a made-up key.

#

Yep, I think your IPv6/WebSocket suspicion is very plausible.

Why I think that:

  • config is clean
  • auth probe passes
  • resolved default is correct
  • no cooldowned profiles
  • DNS resolves, but only to IPv6
  • live Codex turns use WebSocket-first, SSE fallback in auto mode

So the next low-risk thing I’d try is forcing SSE for Codex, which bypasses the WebSocket path entirely:

openclaw config set 'agents.defaults.models["openai-codex/gpt-5.4"].params.transport' sse
openclaw gateway restart
openclaw models status
#

Docs back this config:

  • Codex transport defaults to auto = WebSocket first, SSE fallback
  • per-model override is agents.defaults.models["openai-codex/<model>"].params.transport
  • allowed values are sse, websocket, auto

If that fixes it, then the root problem is very likely container IPv6 / WebSocket connectivity, not OpenClaw auth or quota.

If SSE fixes it, I’d just leave it pinned to sse for now and treat Docker/Hostinger IPv6 as the real networking bug.

If it still fails on SSE, then I’d look next at the container networking layer itself, because at that point it’s not just the WS transport anymore.

Relevant docs:

If you try the SSE pin and paste the result, we can probably close this out pretty fast.

meager pilot
#

SSE transport fix did not work. Still getting empty response bubbles on openai-codex/gpt-5.4 after:

Setting agents.defaults.models["openai-codex/gpt-5.4"].params.transport to sse
Full container restart

Additional finding from models status output:

Configured models now shows a duplicate entry: both openai-codex/gpt-5.4 and "openai-codex/gpt-5.4" (with quotes) — possibly created by the config set command
openclaw gateway restart fails in this Docker environment (no systemd) — using full container restart instead

DNS resolves to IPv6 only for both chatgpt.com and auth.openai.com. Container may not have working IPv6 outbound connectivity — is there a way to force IPv4 for Codex requests, or is there a known issue with Codex OAuth on IPv6-only Docker containers?

molten rockBOT
#

Yeah, at this point I don’t think this is an OpenClaw auth problem anymore.

A few concrete points:

  1. The duplicate quoted model key was from my earlier command, sorry
    You should remove the accidental key named exactly "openai-codex/gpt-5.4" from agents.defaults.models. The real key should be openai-codex/gpt-5.4 without embedded quotes.

  2. SSE failing too is important
    That rules out “just the WebSocket path”.

  3. No, OpenClaw can’t really force IPv4 if the container only gets AAAA answers
    “ipv4first” only helps when both A and AAAA exist. If the container resolver is only handing back IPv6, OpenClaw has no IPv4 address to prefer.

So I’d treat this as a Docker / VPS networking issue now, not a Codex/OAuth issue.

The next checks I’d run inside the container are:

# 
getent ahostsv4 chatgpt.com auth.openai.com
getent ahostsv6 chatgpt.com auth.openai.com
curl -4I https://auth.openai.com || true
curl -6I https://auth.openai.com || true

How to read that:

  • No ahostsv4 output → your resolver/container isn’t getting IPv4 answers, so OpenClaw cannot prefer IPv4.
  • ahostsv6 returns addresses but curl -6 fails → broken IPv6 egress in the container/network, which matches your symptom really well.
  • curl -4 works and ahostsv4 shows A records → then a Node/DNS family preference workaround might help.
  • Both fail → broader container DNS/network issue.

So my recommendation now is:

  • clean the bad quoted config key
#
  • verify ahostsv4/ahostsv6 + curl -4/-6
  • if IPv6 is broken, fix the Docker/Hostinger network or give the container DNS that returns usable A records
  • if the container is truly IPv6-only, then outbound IPv6 needs to actually work, otherwise Codex requests will keep failing regardless of auth state

Full container restart instead of openclaw gateway restart is fine in your setup.

If you paste those four network command results, I can tell you pretty confidently which layer is broken.

meager pilot
#

Network test results:
getent ahostsv4 chatgpt.com
104.18.32.47 STREAM chatgpt.com
172.64.155.209 STREAM

getent ahostsv6 chatgpt.com
(no output - no IPv6 records returned)

curl -4 -I https://chatgpt.com
HTTP/2 403 (Cloudflare challenge - reachable)

curl -6 -I https://chatgpt.com
curl: (7) Failed to connect to chatgpt.com port 443 after 1 ms: Could not connect to server
Summary: IPv4 works (HTTP 403 from Cloudflare = reachable). IPv6 fails completely. But getent hosts chatgpt.com earlier returned only IPv6 addresses, so OpenClaw was trying to connect via IPv6, which is broken in this container.
Root cause confirmed: Container DNS is returning IPv6 addresses but the container has no working IPv6 outbound connectivity. OpenClaw's Codex requests fail because they resolve to IPv6 and can't connect.
Question: What's the best fix — force IPv4 DNS resolution in the container, or is there an OpenClaw config to prefer IPv4?

molten rockBOT
#

Nice, that’s the smoking gun.

Best fix: do it at the container/network layer, not in OpenClaw.

I don’t know of a documented OpenClaw config for “prefer IPv4 for Codex provider requests”. The clean fix is:

  1. Either give the container working IPv6, or
  2. Force the container/Node runtime onto IPv4 preference

For a practical workaround, I’d try setting this on the container:

NODE_OPTIONS=--dns-result-order=ipv4first

Then fully restart the container.

#

If you’re using compose, also giving Docker explicit public DNS is reasonable:

environment:
  NODE_OPTIONS: --dns-result-order=ipv4first
dns:
  - 1.1.1.1
  - 8.8.8.8

A few notes:

  • curl -4 working and curl -6 failing means your app should really be on IPv4 until IPv6 is fixed.
  • Since SSE also failed, this is not a Codex transport quirk anymore.
  • Full container restart is the right equivalent in your setup, since there’s no systemd-managed gateway service.
  • Also delete the accidental quoted model key, that part was my bad.
#

So my recommendation is:

  • short term: NODE_OPTIONS=--dns-result-order=ipv4first
  • real fix: fix Docker/VPS IPv6, or keep the container on IPv4-only networking/DNS

If that works, please mark the solution so Answer Overflow indexes it for the next person:

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

meager pilot
#

NODE_OPTIONS=--dns-result-order=ipv4first in the Docker env did not fix it. IPv4 resolves fine (confirmed earlier with curl -4), but live Codex requests still fail.
Ask them: is there a known issue with Cloudflare's bot challenge (the HTTP 403 with cf-mitigated: challenge we saw on curl -4) blocking OpenClaw's Codex requests specifically? The curl -4 test got a 403 challenge response, not a clean connection — that might be the actual blocker, not IPv6.

molten rockBOT
#

I’m checking the repo for any Codex/Cloudflare challenge handling before I answer, so I don’t make this up.

#

I don’t see a documented OpenClaw-specific known issue for “Codex OAuth gets blocked by Cloudflare challenge pages”.

That said, a few important nuances:

  • Yes, a Cloudflare challenge could absolutely block Codex, because Codex OAuth runtime traffic goes to https://chatgpt.com/backend-api.
  • But your successful models status --probe means this is not a blanket block on all chatgpt.com backend traffic from that container/IP. Some authenticated backend requests are getting through.

So I’d read the curl -4I https://chatgpt.com 403 like this:

  • suspicious
  • not conclusive by itself
  • likely pointing to IP reputation / datacenter challenge behavior
  • but we still need the actual failing Codex response to know if that is the real blocker

Best next check

Grab the real failing runtime error from:

# 
openclaw logs --follow

If the failing Codex turn shows:

  • HTTP 403
  • cf-mitigated
  • HTML/challenge page content

then yes, Cloudflare challenge is very likely the blocker.

If that’s confirmed

There is no OpenClaw config that can bypass Cloudflare bot mitigation.

Practical fixes would be:

#

  1. Try a different egress IP / host / provider
    VPS IP reputation can matter here.

  2. Use direct OpenAI API key route instead of Codex OAuth
    That means openai/* with OPENAI_API_KEY, not openai-codex/*.

  3. File a GitHub issue with sanitized logs if you can show the live Codex request is getting a challenge page:
    https://github.com/openclaw/openclaw/issues

So my short answer is: possible, yes, but not proven yet.
The root curl 403 is not enough on its own, especially since your probe passed. The deciding evidence is the actual live-turn log response.

meager pilot
#

NODE_OPTIONS=--dns-result-order=ipv4first did not fix the issue. Still getting DNS lookup failures and rate limit errors on all openai-codex requests.
The full HTML error body is being truncated in logs — grep "Long error truncated" returns no results in the log file, and the rawErrorPreview in the JSON log entries only shows the beginning of a generic HTML page (CSS styles, no content visible).
IPv4 resolves fine (curl -4 gets HTTP 403 from Cloudflare). The 403 has cf-mitigated: challenge in the response headers — this may be a Cloudflare bot challenge blocking OpenClaw's requests from this VPS IP.
Is there a way to get the full response body from a failed Codex request, or is the Cloudflare challenge the confirmed cause?

molten rockBOT
#

I found the error formatter path, which helps a bit. I’m checking one more spot to see whether rawErrorPreview is the only thing retained or if there’s a hidden full-body field.

#

Yeah, I think you’ve basically found it.

Short version:

  • No, I don’t see a supported runtime flag to log the full failed Codex response body.
  • Yes, the Cloudflare challenge is now the most likely cause.

Why I’m saying that:

  • In current source, OpenClaw’s error observation log only keeps a redacted preview, not the full body.
  • That preview is hard-capped at 400 chars in src/agents/pi-embedded-error-observation.ts (RAW_ERROR_PREVIEW_MAX_CHARS = 400).
  • So the truncated generic HTML snippet you’re seeing is expected. I don’t see a documented config knob to disable that.

And the bigger clue:

  • curl -4 to chatgpt.com from the same VPS gets HTTP 403
  • response header includes cf-mitigated: challenge
  • forcing IPv4 did not fix the live failures
#

At that point, I’d treat this as very likely Cloudflare/IP reputation/bot mitigation on that VPS egress IP, not an OpenClaw auth/config bug.

What this means in practice

OpenClaw can’t bypass a Cloudflare challenge coming from upstream.

Best next moves

  1. Test from a different egress IP / machine / VPS provider

    • If Codex OAuth works there, that basically confirms it.

  2. Use direct OpenAI API key models (openai/*) instead of openai-codex/*

    • good workaround if you need to unblock quickly

  3. If you want full proof, capture outside OpenClaw

    • reverse proxy / packet capture / source patch
    • I do not see a built-in log setting for full raw body
brazen stirrup
molten rockBOT
#

I’m verifying that workaround against the current docs/source before I bless it, mainly because models.mode replace can be a bit sharp.

#

I’m grabbing the issue title so I don’t misstate what that workaround is fixing.

#

Nice find, that workaround looks credible.

I checked current source/docs, and these two parts are real:

  • api: "openai-codex-responses" is a valid supported model API
  • models.mode: "replace" matters here, because in normal merge mode an existing non-empty baseUrl in the agent models.json can win over config

So this likely explains why a plain config override didn’t stick, and why forcing the Codex provider onto the /backend-api/codex path helps.

A couple cautions for anyone trying it:

  • Don’t paste literal models:[...]. Use the full provider object from issue #67193.
  • models.mode: "replace" is a bit sharp, it fully rewrites the provider catalog behavior, so keep that in mind if you have other custom providers.

Docs for the config behavior:

#

So yeah, for now I’d treat issue #67193’s config override as the best known workaround. If this fixes it for anyone else, please add:

  • openclaw --version
  • host/VPS/provider
  • whether you were using Codex OAuth / ChatGPT subscription auth

on that GitHub issue so there’s a clearer trail for maintainers.

celest arch
#

so krill so i think im stuck in exactly the same spot on my end, im having the exact same issue

openclaw config set models.providers.openai-codex
'{"baseUrl":"https://chatgpt.com/backend-api/codex","api":"openai-codex-responses","models":[...]}' --json
openclaw config set models.mode replace

that's the workaround supposedly but is that safe to just set the models to [...] or is that truncated for something else? what's the ACTUAL command that i can actually run to workaround this issue for now?

molten rockBOT
#

Let me pull the built-in Codex provider shape from source so I can give you a real command instead of a fake placeholder.

#

[...] is not something you should paste literally, it’s a placeholder.

If you want the actual temporary workaround for plain Codex OAuth on gpt-5.4, use this:

pnpm openclaw --version
pnpm 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
pnpm openclaw config set models.mode replace
pnpm openclaw gateway restart
pnpm openclaw models list --provider openai-codex

If you use the global CLI, swap pnpm openclaw for openclaw.

Important side effect

models.mode replace is a temporary hammer. It means “use my configured providers instead of the merged built-ins”, so if you only configure openai-codex, your model catalog may effectively narrow to that until you revert.

celest arch
#

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
}
]
}

--- CONFIRMED FIXED

molten rockBOT
#

Hell yes, nice catch, and thanks for posting the full confirmation.

So for anyone landing here later, this is a working temporary fix on 2026.4.14:

  • override models.providers.openai-codex
  • use baseUrl: "https://chatgpt.com/backend-api/codex"
  • set api: "openai-codex-responses"
  • set models.mode to replace
  • restart gateway

And your smoke test confirmed it end-to-end. 🎉

One caveat for future readers: models.mode replace is temporary and can narrow your visible model catalog to configured providers.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
That helps Answer Overflow index it for the next person.

#

Also worth adding your confirmation to issue #67193 with:

  • openclaw --version
  • host/provider
  • that openclaw infer model run passed after the workaround
sacred hamlet
#

Mines doing same thing what is fix so far.. why does openclaw break on every update 😂

molten rockBOT
#

Yeah, that’s annoying 😅 This one looks like a Codex provider regression/workaround situation, not just you.

Current fix people in this thread have confirmed:

pnpm openclaw --version
pnpm 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
pnpm openclaw config set models.mode replace
pnpm openclaw gateway restart
pnpm openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json

If you use the global CLI, swap pnpm openclaw for openclaw.

If that final command returns smoke-ok, you’re unblocked.

One caveat: models.mode replace is a temporary hammer, so it can narrow your model catalog to configured providers.

sacred hamlet
#

could you do npm

molten rockBOT
#

Yep. If you installed with npm globally, the commands are usually just openclaw, not npm openclaw.

So use:

openclaw --version
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
openclaw config set models.mode replace
openclaw gateway restart
openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json

If you specifically want npx, that would be:

npx openclaw --version
# 
npx 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
npx openclaw config set models.mode replace
npx openclaw gateway restart
npx openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json

If that last command prints smoke-ok, you’re good.

sacred hamlet
#

I got back

Restarted systemd service: openclaw-gateway.service
openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json
claudeuser@claude:~$ 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
}
]
}
claudeuser@claude:~$

molten rockBOT
#

Perfect, that means the workaround is working on your box too. 🎉

smoke-ok = Codex OAuth path is alive again.

So at this point you should be able to use openai-codex/gpt-5.4 normally again. If regular chats still misbehave after the smoke test, paste the new error, but the provider itself is clearly responding now.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for future folks.

sacred hamlet
#

Okay it worked. Is this a permanent fix or a plaster to cover?

molten rockBOT
#

Plaster, not permanent.

It’s a workaround that forces Codex onto a different provider path and uses models.mode replace, which is why I wouldn’t treat it as the long-term “correct” state.

So I’d think of it like:

  • good temporary fix
  • safe enough if it’s working
  • worth reverting once the upstream fix lands

Main downside right now:

  • models.mode replace can narrow your model catalog to what you explicitly configured

When a release notes/issue update says this is fixed, revert with:

# 
openclaw config unset models.providers.openai-codex
openclaw config set models.mode merge
openclaw gateway restart

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow.

sacred hamlet
#

Is this going to be patched in a future github update?