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

36 messages · Page 1 of 1 (latest)

jolly adder
#

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

quaint zephyrBOT
true tigerBOT
#

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

quaint zephyrBOT
thorn shuttleBOT
#

Let me check the actual OpenClaw docs copy and the exact troubleshooting path so I don’t guess.

#

I found the relevant docs. I’m checking one more bit for the exact model status wording since that’s useful for provider endpoint problems.

#

That usually means the gateway host cannot resolve the LLM provider hostname, not that the model itself is broken.

Please start with:

openclaw --version
openclaw status
openclaw doctor
openclaw logs --follow

And in the chat/session where it fails:

/model status
#

A few common causes:

  • bad or stale custom baseUrl
  • DNS broken on the VPS/container
  • proxy/firewall blocking outbound HTTPS
  • local/self-hosted provider hostname only resolves on your laptop, not on the gateway host

/model status is especially useful here because it shows the configured provider endpoint (baseUrl) when available.

If you paste:

  • openclaw --version
  • the relevant openclaw logs --follow lines
  • and the baseUrl from /model status

I can usually pinpoint it pretty fast.

Docs:

jolly adder
#

Ziga ~ % /model status
zsh: no such file or directory: /model
Ziga ~ % openclaw --version
OpenClaw 2026.4.14 (323493f)
Ziga@ ~ % openclaw logs --follow

🦞 OpenClaw 2026.4.14 (323493f) — I'm like tmux: confusing at first, then suddenly you can't live without me.

Log file: /tmp/openclaw/openclaw-2026-04-14.log

18:37:28+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"9b03880e-dcf8-41b2-93b0-8c1a8a69bb6f","isError":true,"error":"LLM request failed: DNS lookup for the provider endpoint failed.","failoverReason":null,"model":"gpt-5.2","provider":"openai-codex","rawErrorPreview":"<html>\n <head>\n <meta name="viewport" content="width=device-width, initial-scale=1" />\n <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction:column;gap:2rem;height:100%;justify-content:center;width:100%}@keyframes enlarge-appear{0%{opacity:0;transform:scale(75%) rotate(-90deg)}to{opacity:1;transform:scale(100%) rotate(0deg)}}.lo…","rawErrorHash":"sha256:716bcb7214f5","providerRuntimeFailureKind":"unknown"} embedded run agent end
18:37:43+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"9b03880e-dcf8-41b2-93b0-8c1a8a69bb6f","isError":true,"error":"LLM request failed: DNS lookup for the provider endpoint failed.","failoverReason":null,"model":"gpt-5.2","provider":"openai-codex","rawErrorPreview":"<html>\n <head>\n <meta name="viewport" content="width=device-width, initial-scale=1" />\n <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction:column;gap:2rem;height:100%;justify-content:center;width:100%}@keyframes enlarge-appear{0%{opacity:0;transform:scale(75%) rotate(-90deg)}to{opacity:1;transform:scale(100%) rotate(0deg)}}.lo…","rawErrorHash":"sha256:bac5873b0259","providerRuntimeFailureKind":"unknown"} embedded run agent end
18:37:44+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_succeeded"],"runId":"9b03880e-dcf8-41b2-93b0-8c1a8a69bb6f","decision":"candidate_succeeded","requestedProvider":"anthropic","requestedModel":"claude-haiku-3-5","candidateProvider":"openai-codex","candidateModel":"gpt-5.2","attempt":2,"total":2,"isPrimary":false,"requestedModelMatched":false,"fallbackConfigured":true,"previousAttempts":[{"provider":"anthropic","model":"claude-haiku-3-5","reason":"model_not_found","errorPreview":"Unknown model: anthropic/claude-haiku-3-5","errorHash":"sha256:927e61268c68"}]} model fallback decision
18:37:44+00:00 warn model-fallback {"subsystem":"model-fallback"} Model "anthropic/claude-haiku-3-5" not found. Fell back to "openai-codex/gpt-5.2".
^C%
Ziga ~ % /model status
zsh: no such file or directory: /model
Ziga ~ %

thorn shuttleBOT
#

I’ve got enough to narrow it down. I’m checking the OpenClaw docs for the right CLI command here, because /model status is a chat slash command, not a shell command.

#

One more useful thing: I want to see if the docs call out openai-codex config shadowing, because your logs smell like there may be a custom provider override involved.

#

Ah, yep, /model status is a chat slash command, not a terminal command. In shell, use:

openclaw models status

From your logs, I think there are two separate problems:

  1. anthropic/claude-haiku-3-5 is not found
  2. OpenClaw falls back to openai-codex/gpt-5.2, and that path is failing

The big clue is this part:

  • rawErrorPreview: "<html> ..."

That does not look like a clean DNS failure. It often means one of these instead:

#
  • stale models.providers.openai-codex override
  • proxy/captive portal/HTML error page
  • broken Codex OAuth route/auth state

Please run these next:

openclaw models status
openclaw models list --provider openai-codex
openclaw doctor --deep

What I’m specifically looking for:

  • whether openai-codex auth is missing/expired
  • whether doctor --deep warns about legacy models.providers.openai-codex overrides shadowing the built-in Codex OAuth provider
  • whether your requested primary/fallback model refs are actually valid on this install
jolly adder
#

zsh: no such file or directory: /model
Ziga ~ % openclaw models status

🦞 OpenClaw 2026.4.14 (323493f) — Running on your hardware, reading your logs, judging nothing (mostly).

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

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

  • anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | anthropic:default=token:sk-ant-o...NEns9AAA
  • openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:email=OAuth (email)

OAuth/token status

  • anthropic
    • anthropic:default static
  • openai-codex usage: 5h 100% left ⏱4h 59m · Week 100% left ⏱6d 23h
    • openai-codex:emailok expires in 10d
      Ziga~ %

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

Model Input Ctx Local Auth Tags
openai-codex/gpt-5.2 text+image 266k no yes default,configured
openai-codex/gpt-5.4 text+image 1025k no yes configured
Ziga ~ %

Discord: ok (@t) (449ms)
telegram: ok (t) (236ms)
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): path (5 entries)

  • agent:main:main (9m ago)
  • agent:main:discord:channel:1469038989007913081 (67m ago)
  • agent:main:subagent:55d5fd7e-e104-47b1-81fc-2c0c59774f06 (41623m ago)
  • agent:main:subagent:531d669e-8d0d-4fa6-b4e0-acee432ce653 (41625m ago)
  • agent:main:subagent:344b3062-ae64-4add-92a8-a9c74e364d10 (41631m ago)
    12:47:21 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: momo-memory (/Users/Ziga/.openclaw/extensions/momo-memory/index.ts). Set plugins.allow to explicit trusted ids.
    12:47:21 [plugins] [momo] No API key configured. Set it up at OpenClaw Config → Plugins → All → Momo Memory → Momo API Key

this is all. i want to remove anthropic oauth so its not even considered. and replace it with openai codex oauth which is already set up

thorn shuttleBOT
#

I see the shape now. I’m checking the exact auth/profile commands so I don’t hand you fake CLI. One sec.

#

I found the supported auth commands. There’s a clean way to stop Anthropic from being used, and a more permanent way if you want it gone entirely. Let me verify whether there’s a first-class “remove profile” command or if it’s just config/store cleanup.

#

Nice, this helps a lot.

Two key things:

  1. Your default is already Codex

    • Default: openai-codex/gpt-5.2
    • Fallbacks (0): -

  2. Anthropic is just a stored credential

    • it is not your current default
    • also, in your output it’s a token, not OAuth

So the earlier Anthropic line came from a session/thread model override, not from your global default config.

What to do first

In the Discord thread itself, run:

# 
/model openai-codex/gpt-5.2

or:

/model openai-codex/gpt-5.4

That resets the current session away from the old Anthropic selection.

Important bit

Removing Anthropic auth will stop it from being available, but it will not by itself fix the DNS-ish error, because the provider that actually failed in your logs was openai-codex.

If you want Anthropic completely gone

#

There does not seem to be a first-class models auth remove command right now.

The stored auth lives here:

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

So if you want it truly removed, back that file up, remove the Anthropic profile entry, then restart OpenClaw.

Next if Codex still fails after /model ...

Run:

openclaw doctor --deep
jolly adder
#

OpenClaw doctor
│
◇ Update ──────────────────────────────────────────────────────────────────────────────────╮
│ │
│ This install is not a git checkout. │
│ Run openclaw update to update via your package manager (npm/pnpm), then rerun doctor. │
│ │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Doctor warnings ─────────────────────────────────────────────────────────────────────────╮
│ │
│ - channels.telegram: Telegram is in first-time setup mode. DMs are disabled. Group │
│ messages stay blocked until you add allowed chats under channels.telegram.groups (and │
│ optional sender IDs under channels.telegram.groupAllowFrom), or set │
│ channels.telegram.groupPolicy to "open" if you want broad group access. │
│ │
├───────────────────────────────────────────────────────────────────────────────────────────╯
│

#

◇ Archive 1 orphan transcript file in ~/.openclaw/agents/main/sessions? This only renames them to *.deleted.<timestamp>.
│ Yes
│
◇ State integrity ──────────────────────────────────────────────────────────────────────────╮
│ │
│ - OAuth dir not present (~/.openclaw/credentials). Skipping create because no │
│ WhatsApp/pairing channel config is active. │
│ - Found 1 orphan transcript file in ~/.openclaw/agents/main/sessions. │
│ These .jsonl files are no longer referenced by sessions.json, so they are not part of │
│ any active session history. │
│ Doctor can archive them safely by renaming each file to *.deleted.<timestamp>. │
│ Examples: │
│ c69bcb72-b764-4659-8516-52dc9e91417b.checkpoint.60a81b41-cb09-411c-b4a6-b18ab4a6e52b.j │
│ sonl │
│ │
├────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Doctor changes ──────────────────────────────────────────────────────────────────────╮
│ │
│ - Archived 1 orphan transcript file in ~/.openclaw/agents/main/sessions as .deleted │
│ timestamped backups. │
│ │
├───────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Security ─────────────────────────────────────────────────────────────────────────────╮
│ │
│ - Heartbeat defaults: heartbeat delivery is configured while │
│ agents.defaults.heartbeat.directPolicy is unset. │
│ Heartbeat now allows direct/DM targets by default. Set it explicitly to "allow" or │
│ "block" to pin upgrade behavior. │
│ - Run: openclaw security audit --deep │
│ │
├────────────────────────────────────────────────────────────────────────────────────────╯
│
◇ Skills status ────────────╮
│ │
│ Eligible: 38 │
│ Missing requirements: 18 │
│ Blocked by allowlist: 0 │
│ │
├────────────────────────────╯
12:52:17 [plugins] [momo] No API key configured. Set it up at OpenClaw Config → Plugins → All → Momo Memory → Momo API Key
│
◇ Plugins ──────╮
│ │
│ Loaded: 58 │
│ Imported: 58 │
│ Disabled:

thorn shuttleBOT
#

Yeah, that doctor output is a red herring.

The Telegram warning is unrelated, and plain doctor didn’t surface anything about the model path.

Please run the exact two commands:

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

And in the Discord thread, also do:

/model openai-codex/gpt-5.2
#

or gpt-5.4 if that’s the one you want.

Why: right now we still need to answer two things:

  1. is the thread/session still pinned to the old Anthropic model?
  2. does the openai-codex provider actually probe cleanly on this host?

--probe is a real request, so it may consume a tiny bit of usage.

Paste those outputs and we should be very close.

#

Good news, doctor --deep still isn’t showing any Codex override/TLS warning.

Everything in that output looks unrelated:

  • orphan transcript archive, harmless
  • heartbeat default warning, unrelated
  • momo plugin warning, unrelated

So the one thing we still need is the live Codex probe:

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

And please also do the session reset in the Discord thread:

# 
/model openai-codex/gpt-5.2

Then retry once.

If it still breaks, paste:

  1. the --probe output
  2. the fresh openclaw logs --follow line from that retry

We’re basically down to “session pinned weirdly” vs “Codex provider path is failing on this host.”

jolly adder
#

ive done both. what i posted above is the two commands and when i ran model openai command in discord i got LLM request failed: DNS lookup for the provider endpoint failed.

what is the dns here and how can i fix it

thorn shuttleBOT
#

I want to give you the concrete hostname to test, not hand-wave “DNS”. I’m checking the OpenClaw source for which endpoint openai-codex actually resolves on this version.

#

Yep, that’s frustrating, but we can be concrete now.

DNS here means your Mac trying to turn the provider hostname into an IP address.

For openai-codex, the important hostname is most likely:

  • chatgpt.com (Codex OAuth/native route uses chatgpt.com/backend-api)
  • sometimes api.openai.com too

So the failure is basically: OpenClaw tries to reach that host, and name resolution or network routing is going sideways.

Test it on the same Mac running OpenClaw

nslookup chatgpt.com
nslookup api.openai.com
# 
curl -I https://chatgpt.com
curl -I https://api.openai.com/v1/models

If nslookup fails

It’s a real DNS/network problem on the machine. Common causes:

  • VPN / corporate proxy
  • AdGuard / NextDNS / Pi-hole / little snitch style filtering
  • captive portal / weird Wi‑Fi DNS
  • bad custom /etc/hosts
  • proxy env vars pointing somewhere broken

Fast things to try

  • turn VPN/adblock/filtering off temporarily
  • switch networks, for example hotspot
#
  • restart Wi‑Fi
  • try different DNS servers, for example Cloudflare 1.1.1.1 or Google 8.8.8.8
  • check proxy env:
env | egrep '^(HTTP|HTTPS|ALL|NO)_PROXY='

One more clue

Your earlier rawErrorPreview was HTML, which makes me suspect a proxy/intercept/login page even more than a pure DNS failure.

So if nslookup works but OpenClaw still fails, I’d try:

openclaw models auth login --provider openai-codex
#

and also test on a different network.

If you paste the output of:

nslookup chatgpt.com
nslookup api.openai.com
env | egrep '^(HTTP|HTTPS|ALL|NO)_PROXY='

I can tell you which branch this is pretty quickly.

random plume
#

same issue and I'm getting a ** server can't find api.openai.com~: NXDOMAIN

thorn shuttleBOT
#

That ~ is the giveaway.

api.openai.com~ is not the real hostname, so NXDOMAIN there is expected.

Try exactly:

nslookup api.openai.com
nslookup chatgpt.com

No trailing ~, no punctuation.

If those resolve, DNS is probably fine and the failure is somewhere else.

If they still fail, then it’s a real local DNS issue, usually one of: