#DNS Lookup for the provider endpoint failed

1 messages · Page 1 of 1 (latest)

pliant elm Apr 16, 2026, 3:52 PM

OpenClaw on my Mac mini is correctly set to use ChatGPT Plus OAuth with openai-codex/gpt-5.4, but every real Codex request to chatgpt.com/backend-api gets blocked by Cloudflare (403 cf-mitigated: challenge / websocket 401), so OpenClaw shows “DNS lookup for the provider endpoint failed.”
The same OpenClaw version and same account work fine on my Hostinger VPS, so the issue looks specific to this Mac/network path, not my subscription or OpenClaw config.

languid trellisBOT Apr 16, 2026, 3:52 PM

pliant elm Apr 16, 2026, 3:53 PM

peak arrowBOT Apr 16, 2026, 3:56 PM

Let me check the docs and the exact error path so I don’t guess.

I found one important thing in the code: that “DNS lookup for the provider endpoint failed” message is a generic sanitizer. It can show up for broader network/provider-path failures, so it can definitely mask the underlying Cloudflare block you saw.

This doesn’t sound like real DNS.

I checked the docs/code, and OpenClaw currently sanitizes several provider/network failures into the generic message:

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

So a Cloudflare 403 cf-mitigated or WS 401 can absolutely show up as that misleading text.

Since the same account works on your VPS, I’d treat this as a Mac egress / local network path issue, not a subscription/config entitlement issue.

Please paste these first:

openclaw --version
openclaw status --all
openclaw models status

openclaw doctor --deep
openclaw config get models.providers.openai-codex

Most likely culprits on the Mac:

iCloud Private Relay, VPN, proxy, DNS filter, Pi-hole
Little Snitch / LuLu / antivirus HTTPS inspection
a stale models.providers.openai-codex override shadowing the built-in Codex OAuth path
local TLS stack weirdness, which doctor --deep now checks for Codex OAuth on macOS

Fastest experiments:

Try a different egress path, phone hotspot is perfect
Temporarily disable Private Relay / VPN / HTTPS-inspecting tools
If only WebSocket is failing, force SSE as a test:

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

Docs:

If you paste those outputs plus one raw failing log block, I can help narrow it down pretty quickly.

Yeah, I think your read is basically right.

403 cf-mitigated means Cloudflare is challenging that specific Mac/network path. OpenClaw can’t solve that challenge in the Codex backend flow, so the request dies, then the UI/error sanitizer turns it into the misleading “DNS lookup…” message.

So in practice:

not a ChatGPT Plus entitlement problem
probably not an OpenClaw auth problem
very likely Mac egress / local network / local TLS-intercept / IP reputation

Also, forcing SSE is only a diagnostic. If the plain HTTPS request is already getting cf-mitigated, SSE won’t magically fix it.

What I’d test on the Mac, in this order:

Different egress path
- phone hotspot is the best quick test
Disable network meddling

iCloud Private Relay
- VPN / WARP / exit node
- proxy
- Little Snitch / LuLu
- AdGuard / NextDNS / antivirus HTTPS inspection

Run doctor

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

One more thing I checked in the docs/code: if you ever added a custom models.providers.openai-codex transport override, that can shadow the built-in Codex OAuth route. So that last config get output matters.

If the hotspot test works, that’s basically your answer: the Mac’s normal network path is what Cloudflare dislikes.

At that point the real options are:

keep Codex OAuth on the VPS
switch the Mac to openai/* with an API key instead of ChatGPT OAuth
change the Mac’s egress/network path

Docs:

If you paste those command outputs, I can help narrow it down fast.

pliant elm Apr 16, 2026, 3:58 PM

Maybe I should reset my Mac and onboard again ?

peak arrowBOT Apr 16, 2026, 3:58 PM

I wouldn’t reset the Mac, no.

A full Mac reset or even a full OpenClaw re-onboard is unlikely to fix cf-mitigated, because that usually points to the network/egress path, not broken local config.

I’d do these cheaper tests first:

Phone hotspot test
- if it works there, you’ve basically proven it’s the normal network path
Temporarily disable
- iCloud Private Relay
- VPN / WARP / proxy / exit node
- Little Snitch / LuLu / AdGuard / HTTPS inspection
Low-cost OpenClaw reset only
- re-auth Codex, not the whole machine: