OpenClaw 2026.4.12/14 with openai-codex/gpt-5.4 stalls indefinitely in TUI. | Friends of the Crustacean 🦞🤝 | Page 1

clever quartz Apr 16, 2026, 4:22 AM

#

Issue: OpenClaw 2026.4.14 with openai-codex/gpt-5.4 stalls indefinitely in TUI (“noodling”). No responses returned.

Errors alternate between:
• “DNS lookup for provider endpoint failed”
• “API rate limit reached”

Logs consistently show:
rawError=”…” (Cloudflare page)

Key finding:
This is not DNS. The provider returns a Cloudflare HTML challenge/block page instead of JSON. OpenClaw misclassifies this as DNS or rate limit.

Environment:
• macOS
• OpenClaw 2026.4.14
• Codex CLI auth (codex login –device-auth)
• ~24 cron jobs + channels + memory-core initially enabled

Steps taken:
1. Fixed auth + model:
• codex login –device-auth
• openclaw models auth login –provider openai-codex
• set agents.defaults.model.primary=openai-codex/gpt-5.4
2. Disabled all background traffic:
• cron.enabled=false
• discord/telegram disabled
• memory-core disabled

Result:
• Background request storm eliminated
• Still stalls with single request
• Still receives HTML Cloudflare responses

Behavior:
Startup → requests hit Cloudflare → HTML returned → misclassified → retries escalate → eventual stuck session
Even after cooldown and no background traffic, single requests hang or return HTML.

Conclusion:
Cloudflare challenge responses are not handled correctly in 4.14 for openai-codex. Causes misclassification (DNS/rate limit) and eventual stuck provider session.

Next step:
Testing rollback to 4.12 to confirm regression.

4.12 is doing the same thing

mellow forge Apr 16, 2026, 4:24 AM

#

Having exact same issue!

clever quartz Apr 16, 2026, 4:25 AM

#

I feel your pain, this is so frustrating

junior zealotBOT Apr 16, 2026, 4:25 AM

#

Let me verify against the actual docs and provider code, one sec.

#

Yeah, I think your read is basically right. This does not sound like real DNS.

I checked current docs + source, and OpenClaw already has special handling for 5xx HTML / Cloudflare pages plus fallback on 521/522/523/524/etc. So if you’re getting “DNS lookup failed” or generic “rate limit reached” from an HTML challenge page, that points to error misclassification, not an actual resolver issue.

Also, since 4.12 does the same thing, I would not treat this as a 4.14-only regression. More likely:

upstream Codex OAuth traffic is getting a Cloudflare block/challenge, and
one of the OpenClaw error paths is normalizing that badly.

A couple useful next steps:

1. Repro it with the smallest possible call

openclaw --version
openclaw infer model run --model openai-codex/gpt-5.4 --prompt "reply with ok" --json
openclaw logs --follow

#

2. Try forcing SSE
Docs say openai-codex/* is WebSocket-first with SSE fallback, so this is worth testing:

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

#

If SSE works and auto/websocket does not, that narrows it a lot.

3. Short-term unblock
If you just need it working today, try:

codex-cli/gpt-5.4 as a fallback path, or
openai/gpt-5.4 with an API key, if you have one.

At this point I’d file a GitHub issue with:

exact openclaw --version
minimal repro command
first raw HTML status line / snippet (521, 403, etc.)
whether transport: "sse" changes behavior

Bug reports go here: https://github.com/openclaw/openclaw/issues

Docs:

OpenAI provider / transport: https://docs.openclaw.ai/providers/openai

#

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

If you want, paste one redacted rawError= sample and I can help turn it into a tight issue report.

#

That’s actually really helpful, seeing a second report makes this look a lot less machine-specific.

If you can, please add the same 3 bits when the issue gets filed:

exact openclaw --version
whether forcing transport: "sse" changes anything
the first redacted rawError= HTML status / snippet

For immediate unblock, the best tests are still:

codex-cli/gpt-5.4
or openai/gpt-5.4 with an API key
or force SSE for openai-codex/gpt-5.4

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

If one of you posts the redacted raw error, I can help tighten the repro.

#

Yeah, totally. This kind of bug is extra annoying because it looks like DNS/rate-limit noise when the real problem is upstream HTML getting shoved through the wrong error path.

The upside is, with multiple people seeing it, it’s starting to look like a real reproducible bug instead of one cursed machine.

If you want, paste a redacted rawError= block and I’ll turn it into a clean GitHub issue body.

clever quartz Apr 16, 2026, 4:36 AM

#

do I need to censor anything out of the logs it generated

junior zealotBOT Apr 16, 2026, 4:36 AM

#

Yeah, in public I’d redact anything credential-ish.

Definitely censor:

Authorization: headers
bearer tokens, API keys, refresh/access/id tokens
cookies / session cookies
gateway token / password / device tokens
email addresses if you don’t want them public
full config blobs if they include secrets

Usually fine to keep:

model name (openai-codex/gpt-5.4)
HTTP status (403/429/521/etc.)
the HTML title/body snippet showing Cloudflare
stack traces / error text
request_id / cf-ray if present, those can actually help

#

Nice safe pattern:

keep the first 20 to 50 lines around the first failure
replace secrets with [REDACTED]

Example:

rawError="521 <!DOCTYPE html><html>...Cloudflare...</html>"
Authorization: Bearer [REDACTED]
refresh_token=[REDACTED]

If you paste it here, I can do a quick sanity check before it goes into a GitHub issue.

clever quartz Apr 16, 2026, 4:44 AM

#

warn bonjour watchdog detected non-announced service; attempting re-advertise
(gateway fqdn=[REDACTED].local host=openclaw.local port=18789 state=probing)
info bonjour advertised gateway fqdn=[REDACTED].local host=openclaw.local port=18789 state=announcing

info heartbeat started intervalMs=1800000
info cron started enabled=true jobs=XX

info discord starting provider (@REDACTED)
info telegram starting provider (@REDACTED)

info lossless-claw initialized db=~/.openclaw/lcm.db
info lossless-claw compaction model=openai-codex/gpt-5.4

info Discord ok
info Telegram ok
info Agents main
info Heartbeat interval 30m

info session store ~/.openclaw/agents/main/sessions entries=XX
info sessions:

agent:main:main
agent:main:cron:***
agent:main:other:***

info discord channels resolved [REDACTED]
info discord users resolved [REDACTED]

warn discord command truncated lossless description shortened

info gateway ws ok doctor.memory.status
info gateway ws ok chat.history

info gateway received SIGTERM; restarting

info gateway starting
info gateway ready plugins=discord,lossless-claw,memory-core,memory-wiki,telegram

warn agent errors:

API rate limit reached
DNS lookup for provider endpoint failed

warn errors:

HTML error truncated
Cloudflare 521 response

warn telegram network:

enabling IPv4-only fallback dispatcher

info lossless-claw:

bootstrap complete session=***
assemble using live context
compaction skipped below threshold

info gateway ws ok chat.history

junior zealotBOT Apr 16, 2026, 4:45 AM

#

This looks pretty well redacted already 👍

Nothing here jumps out as sensitive anymore, beyond anything you personally don’t want public. The only extra things I might still mask are:

local hostnames like openclaw.local
exact session ids / counts, if you care

The important lines are these:

warn agent errors:
- API rate limit reached
- DNS lookup for provider endpoint failed

warn errors:
- HTML error truncated
- Cloudflare 521 response

#

That’s the juicy part, because it shows the mismatch pretty cleanly.

One important note though: this snippet still shows:

info cron started enabled=true
info discord starting provider
info telegram starting provider
info gateway ready plugins=discord,lossless-claw,memory-core,memory-wiki,telegram

So if you file the issue, I’d explicitly say whether this log was from before or after disabling background traffic. Otherwise it’ll look like cron/channels/memory were still active during the repro.

Also:

bonjour watchdog... is probably unrelated
telegram IPv4-only fallback is probably unrelated
gateway received SIGTERM; restarting is worth mentioning only if the restart was unexpected

#

If you want, I can turn this into a tight issue body now.

clever quartz Apr 16, 2026, 4:45 AM

#

04:16:00+00:00 info gateway/ws ⇄ res ✓ chat.history 70ms conn=*** id=***
04:16:04+00:00 info {"plugin":"lossless-claw"} [lcm] Reusing shared engine init for db=~/.openclaw/lcm.db
04:16:05+00:00 info {"plugin":"lossless-claw"} [lcm] Reusing shared engine init for db=~/.openclaw/lcm.db
04:16:05+00:00 info {"plugin":"lossless-claw"} [lcm] Reusing shared engine init for db=~/.openclaw/lcm.db
04:16:05+00:00 info {"plugin":"lossless-claw"} [lcm] bootstrap: session queue acquired queueKey=*** queuedAhead=0 wait=0ms session=*** sessionKey=***
04:16:05+00:00 info {"plugin":"lossless-claw"} [lcm] bootstrap: append-only conversation=*** session=*** existingCount=25 appendedMessages=0 importedMessages=0 duration=4ms
04:16:05+00:00 info {"plugin":"lossless-claw"} [lcm] bootstrap: done session=*** bootstrapped=false importedMessages=0 reason=already bootstrapped duration=4ms
04:16:05+00:00 info {"plugin":"lossless-claw"} [lcm] maintain: session queue acquired queueKey=*** queuedAhead=0 wait=0ms session=***
04:16:05+00:00 info {"plugin":"lossless-claw"} [lcm] assemble: falling back to live context conversation=*** contextItems=25 liveMessages=55 duration=1ms

04:16:12+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"API rate limit reached","failoverReason":"rate_limit",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

04:16:22+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"API rate limit reached","failoverReason":"rate_limit",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

04:16:33+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"DNS lookup for provider endpoint failed",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

#

04:16:49+00:00 warn errors Long error truncated: <html>...
04:16:49+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"<html>...","model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

04:16:49+00:00 info {"plugin":"lossless-claw"} [lcm] ingestBatch: session queue acquired queueKey=*** queuedAhead=0 wait=0ms session=*** messages=2
04:16:49+00:00 info {"plugin":"lossless-claw"} [lcm] incremental compaction decision:
cacheState=cold activityBand=low threshold=20000 shouldCompact=false reason=below-leaf-trigger

04:16:49+00:00 info {"plugin":"lossless-claw"} [lcm] afterTurn: done conversation=*** session=*** newMessages=2 ingestedMessages=2 duration=7ms
04:16:49+00:00 info {"plugin":"lossless-claw"} [lcm] maintain: session queue acquired queueKey=*** queuedAhead=0 wait=0ms session=***

junior zealotBOT Apr 16, 2026, 4:45 AM

#

This snippet is useful, and it’s safe enough as posted.

What it shows pretty clearly:

same provider/model every time: openai-codex / gpt-5.4
multiple failures within ~20s
classification flips from rate_limit to DNS lookup failed

That’s a pretty good signal that OpenClaw is normalizing the same underlying upstream failure inconsistently, not that you suddenly had real DNS breakage mid-run.

The one thing still missing for a strong bug report is the raw upstream payload right before these lines, ideally the part that shows:

Cloudflare 521
HTML error truncated
or rawError=...

These embedded_run_agent_end lines are already the post-classification result, so they prove the symptom, but not the original response body.

#

Also, the lossless-claw lines mostly look like background context assembly noise, not the smoking gun.

If you want, this is basically the issue-summary sentence I’d use:

Repeated openai-codex/gpt-5.4 requests fail within the same session, and OpenClaw alternately classifies them as rate_limit and DNS lookup failed, while separate logs show a Cloudflare 521 HTML response. This suggests the same upstream HTML/block response is being mapped to inconsistent failover reasons.

If you paste the rawError= bit too, I can turn the whole thing into a ready-to-post issue body.

#

Oh, this is much better. This is basically the smoking gun.

The key lines are:

warn errors Long error truncated: <html>...
warn agent/embedded ... "error":"<html>..." ... "provider":"openai-codex"

That means OpenClaw is not even getting a normal JSON provider error there, it’s getting literal HTML back and surfacing that into the embedded error path. So yeah, this is very hard to explain as real DNS.

The lossless-claw lines after that look incidental.

At this point I think you have enough for a solid issue. Something like:

#

## Summary
`openai-codex/gpt-5.4` stalls indefinitely in TUI. Upstream appears to return an HTML page (Cloudflare / 521), but OpenClaw inconsistently classifies the failure as rate limit, DNS failure, or raw `<html>...`.

## Environment
- macOS
- OpenClaw 2026.4.12 and 2026.4.14
- Codex OAuth auth (`codex login --device-auth`, `openclaw models auth login --provider openai-codex`)

## Minimal behavior observed
Logs show:
- `Cloudflare 521 response`
- `Long error truncated: <html>...`
- `error":"<html>...","provider":"openai-codex"`
- alternate user-facing failures:
  - `API rate limit reached`

#

  - `DNS lookup for provider endpoint failed`

## Expected
HTML / Cloudflare upstream failures should be classified consistently as upstream HTTP/service errors, not DNS or rate-limit errors, and should not leave the session stuck/noodling.

## Actual
The same underlying upstream failure appears to be mapped inconsistently, retries escalate, and the session stalls.

I’d post that to https://github.com/openclaw/openclaw/issues.

If you want, I can tighten it one more pass with your exact openclaw --version line.

clever quartz Apr 16, 2026, 4:48 AM

#

OpenClaw 2026.4.12 (1c0672b)

note I just downgraded to see if this might fix the issue, same as in 4.14, it didn't happen until OC was updated to 4.14

junior zealotBOT Apr 16, 2026, 4:48 AM

#

That’s a really important nuance.

I’d phrase it like this in the issue:

First observed immediately after updating to 2026.4.14.
After downgrading to 2026.4.12 (1c0672b), the same behavior persists.

That keeps the timeline accurate without over-claiming a clean 4.14 regression.

Honestly, that points a bit more toward one of these:

a provider-side / Cloudflare-side change
some local auth/session state that survived the downgrade
or a bug that 4.14 exposed, but 4.12 can still hit once the state is bad

So I would not title it “4.14 regression” now. I’d title it more like:

openai-codex/gpt-5.4 returns Cloudflare HTML, gets misclassified as DNS/rate-limit, session stalls

#

That title is tighter and harder to argue with.

clever quartz Apr 16, 2026, 4:48 AM

#

do you need my github account?

junior zealotBOT Apr 16, 2026, 4:49 AM

#

Nope, I don’t need your GitHub account.

Just file it yourself here: https://github.com/openclaw/openclaw/issues

I can help with:

the title
the issue body
what logs to include
a quick sanity check before you post

I just can’t open the issue on your behalf. If you want, I can write the final copy-and-paste version now.

clever quartz Apr 16, 2026, 4:49 AM

#

ok lets get this filed

junior zealotBOT Apr 16, 2026, 4:49 AM

#

Yep. Paste this into GitHub and tweak anything you want:

Title
openai-codex/gpt-5.4 returns Cloudflare HTML and gets misclassified as rate_limit / DNS, leaving TUI stuck

Body

## Summary

`openai-codex/gpt-5.4` stalls indefinitely in the TUI ("noodling") and never returns a response.

The upstream response appears to be an HTML / Cloudflare error page rather than a normal JSON provider error, but OpenClaw inconsistently classifies it as:

- `API rate limit reached`
- `DNS lookup for provider endpoint failed`
- raw `<html>...`

#


This leaves the provider/session path stuck even when background traffic is disabled and only a single request is being made.

## Environment

- macOS
- OpenClaw 2026.4.14 (this is when I first observed the problem)
- Downgraded to OpenClaw 2026.4.12 (`1c0672b`) and the same behavior persisted
- Codex OAuth auth via:
  - `codex login --device-auth`
  - `openclaw models auth login --provider openai-codex`
- Model: `openai-codex/gpt-5.4`

## What I tried

#

1. Fixed auth + model:
   - `codex login --device-auth`
   - `openclaw models auth login --provider openai-codex`
   - set `agents.defaults.model.primary = openai-codex/gpt-5.4`

2. Disabled background traffic to rule out request storms:
   - `cron.enabled = false`
   - Discord / Telegram disabled
   - memory-core disabled

## Result

Disabling background traffic reduced the request storm, but did **not** fix the issue.

Even with a single request after cooldown, OpenClaw still hangs or surfaces HTML / Cloudflare responses.

#


## Expected behavior

If the upstream returns an HTML / Cloudflare page, OpenClaw should classify it consistently as an upstream HTTP/service failure, not as DNS or rate limiting, and it should fail cleanly instead of leaving the session stuck.

## Actual behavior

OpenClaw appears to receive an HTML response and then inconsistently maps the same underlying upstream failure to different user-facing / failover errors, including:

- `API rate limit reached`
- `DNS lookup for provider endpoint failed`
- raw `<html>...`

This leads to retries/escalation and an indefinitely stuck TUI session.

#

## Sanitized log excerpts

```text
warn errors:
- HTML error truncated
- Cloudflare 521 response

04:16:12+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"API rate limit reached","failoverReason":"rate_limit",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

04:16:22+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"API rate limit reached","failoverReason":"rate_limit",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

#

04:16:33+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"DNS lookup for provider endpoint failed",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end


```text
04:16:49+00:00 warn errors Long error truncated: <html>...
04:16:49+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"<html>...","model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

Notes

I first noticed this after updating to 2026.4.14.
Downgrading to 2026.4.12 did not clear the issue.
That makes me unsure whether this is a pure 4.14 regression vs. an upstream/provider-side or persisted local-state issue.

#

- Another user in the Discord help thread reported the same symptom.

If you want, paste the issue link back here after posting and I’ll do one last pass on it.

clever quartz Apr 16, 2026, 4:52 AM

#

Create new issue in openclaw/openclaw: Bug report ?

junior zealotBOT Apr 16, 2026, 4:53 AM

#

Yep, choose “Bug report.”

I can’t create the GitHub issue for you, but that’s the right issue type here:
https://github.com/openclaw/openclaw/issues/new/choose

Then paste in the title/body we drafted. If you want, send me the final draft before you hit submit and I’ll sanity check it.

clever quartz Apr 16, 2026, 4:56 AM

#

Sorry I have a small screen and your titles do not match what github is asking for

junior zealotBOT Apr 16, 2026, 4:57 AM

#

No worries. Do this:

Tap Bug report
In the Title field, paste exactly this:

openai-codex/gpt-5.4 returns Cloudflare HTML and gets misclassified as rate limit / DNS, leaving TUI stuck

In the big description/body box, paste the longer text.

If GitHub is showing a template with sections, use this super short version:

Title
openai-codex/gpt-5.4 returns Cloudflare HTML and gets misclassified as rate limit / DNS, leaving TUI stuck

What happened
openai-codex/gpt-5.4 stalls indefinitely in the TUI. Logs show Cloudflare / HTML responses, but OpenClaw alternately reports:

API rate limit reached

#

DNS lookup for provider endpoint failed
raw <html>...

Expected behavior
Cloudflare / HTML upstream failures should be classified consistently as upstream HTTP/service errors and fail cleanly, not as DNS or rate-limit errors, and should not leave the session stuck.

Environment

macOS
OpenClaw 2026.4.14
Downgraded to OpenClaw 2026.4.12 (1c0672b), same behavior persisted
Codex OAuth via codex login --device-auth
openclaw models auth login --provider openai-codex
model: openai-codex/gpt-5.4

Additional context

First noticed after updating to 2026.4.14
Disabling cron/channels/memory-core reduced background traffic but did not fix single-request repro

#

Logs include Cloudflare 521 response, Long error truncated: <html>..., and alternating rate_limit / DNS classification

If you want, send me a screenshot of the fields it shows and I’ll map each section 1:1.

clever quartz Apr 16, 2026, 5:01 AM

#

Bug type
Beta release blocker
Summary
Steps to reproduce
Expected behavior
Actual behavior
OpenClaw version
Operating system
Install method
Model
Provider / routing chain
Additional provider/model setup details
Logs, screenshots, and evidence
Impact and severity
Additional information

these are the fields it needs

junior zealotBOT Apr 16, 2026, 5:02 AM

#

Perfect, use this field-by-field.

Bug type
Beta release blocker
(If there’s also a plain “bug” option and you prefer that, that’s fine too.)

Summary
openai-codex/gpt-5.4 stalls indefinitely in the TUI. Logs show Cloudflare / HTML responses, but OpenClaw misclassifies the failure as API rate limit reached, DNS lookup for provider endpoint failed, or raw <html>....

Steps to reproduce

Authenticate Codex OAuth:
- codex login --device-auth
- openclaw models auth login --provider openai-codex
Set model to openai-codex/gpt-5.4
Start a normal TUI/session prompt
Observe the session stall/noodle without a real response
Check logs, which show Cloudflare / HTML responses and inconsistent classification (rate_limit, DNS, raw <html>)

#

Expected behavior
Cloudflare / HTML upstream failures should be classified consistently as upstream HTTP/service errors and fail cleanly, not as DNS or rate-limit errors, and should not leave the TUI session stuck.

Actual behavior
The same underlying upstream failure appears to be mapped inconsistently:

API rate limit reached
DNS lookup for provider endpoint failed
raw <html>...

The session retries/escalates and ends up stuck/noodling.

OpenClaw version
First observed on 2026.4.14. Downgraded to 2026.4.12 (1c0672b) and the same behavior persisted.

Operating system
macOS

#

Install method
[replace with your actual install method, e.g. npm global / pnpm / Homebrew / source]

Model
gpt-5.4

Provider / routing chain
openai-codex/gpt-5.4 via Codex OAuth (not openai/gpt-5.4 API key route)

Additional provider/model setup details

codex login --device-auth
openclaw models auth login --provider openai-codex
default model set to openai-codex/gpt-5.4
disabling cron/channels/memory-core reduced background traffic but did not fix single-request repro

Logs, screenshots, and evidence

#

warn errors:
- HTML error truncated
- Cloudflare 521 response

04:16:12+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"API rate limit reached","failoverReason":"rate_limit",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

04:16:22+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"API rate limit reached","failoverReason":"rate_limit",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

04:16:33+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,

#

"error":"DNS lookup for provider endpoint failed",
"model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

04:16:49+00:00 warn errors Long error truncated: <html>...
04:16:49+00:00 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,
"error":"<html>...","model":"gpt-5.4","provider":"openai-codex"} embedded run agent end

Impact and severity
High. Blocks normal interactive use of openai-codex/gpt-5.4 in the TUI and leaves sessions stuck.

Additional information

I first noticed this after updating to 2026.4.14
Downgrading to 2026.4.12 did not clear it

#

This makes it unclear whether this is a pure 4.14 regression vs. an upstream/provider-side or persisted local-state issue
Another user in the Discord help thread reported the same symptom

If you want, paste just your Install method here and I’ll give you the final exact text for that field too.

clever quartz Apr 16, 2026, 5:09 AM

#

I did the 4.14 update from openclaw and there was an npm command you posted for a downgrade for some other help

junior zealotBOT Apr 16, 2026, 5:09 AM

#

Yep, then I’d put this for Install method:

npm global install (updated via OpenClaw tooling, downgraded with npm command)

If you want the shorter version, this is also fine:

npm global

That should be enough for the issue template. If you post the issue link, I’ll check it quickly.

clever quartz Apr 16, 2026, 5:10 AM

#

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

junior zealotBOT Apr 16, 2026, 5:10 AM

#

Nice, this looks solid. I’m glad you got it filed.

It’s already good enough for triage. The only optional follow-ups I’d add as a comment later, if you get them, are:

exact 2026.4.14 version string / commit
whether forcing transport: "sse" changes the behavior
one slightly less-truncated rawError= / HTML snippet, if you have it

But honestly, the issue as filed already makes the problem pretty clear.

If this thread helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future folks.

clever quartz Apr 16, 2026, 5:12 AM

#

even if the solution was to file a ticket?

junior zealotBOT Apr 16, 2026, 5:13 AM

#

Yep, that’s totally fine.

You’d be marking the support thread as solved, not claiming the underlying bug is fixed. In this case, the practical resolution was:

identify it’s likely not real DNS
gather the right logs
file the GitHub issue

That’s exactly the kind of thing Answer Overflow should index.

clever quartz Apr 16, 2026, 5:13 AM

#

is it marked correctly?

junior zealotBOT Apr 16, 2026, 5:14 AM

#

If you only added the ❤️ reaction, then not yet. That’s just a normal reaction.

To mark it for Answer Overflow, do:

right-click the solution message → Apps → ✅ Mark Solution

If you already did that too, then yep, you’re good.

clever quartz Apr 16, 2026, 5:15 AM

#

The application did not respond, directly messaged to me

junior zealotBOT Apr 16, 2026, 5:15 AM

#

Ah, got it. That’s probably Discord/App weirdness, not you.

A few options:

try again from desktop or web
right-click the message again, then Apps → Mark Solution
if it keeps failing, don’t sweat it, the important part is the issue is filed already

So, nice work. We got the bug documented either way.

clever quartz Apr 16, 2026, 5:15 AM

#

After marking the solution with the green checkmark

junior zealotBOT Apr 16, 2026, 5:15 AM

#

Yep, if you got the green checkmark, then it’s marked correctly ✅

Nice, thank you. That’ll help future people find the thread.

tiny matrix Apr 16, 2026, 5:43 AM

#

same issue

junior zealotBOT Apr 16, 2026, 5:43 AM

#

Thanks, another report helps a lot.

If you can, please add your:

exact openclaw --version
OS
whether forcing transport: "sse" changes anything

to the issue here: https://github.com/openclaw/openclaw/issues/67517

That’ll help show it’s not just one machine.

tiny matrix Apr 16, 2026, 5:53 AM

#

codex-cli/gpt-5.4 was helpful

junior zealotBOT Apr 16, 2026, 5:53 AM

#

Nice, that’s a really useful data point.

If codex-cli/gpt-5.4 works while openai-codex/gpt-5.4 breaks, that points more toward the OpenClaw openai-codex provider path / transport / error handling, not GPT-5.4 itself.

If you can, please add that to the issue too:
https://github.com/openclaw/openclaw/issues/67517

That helps narrow it down a lot.

clever quartz Apr 16, 2026, 6:40 AM

#

openclaw config set 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"
}
]
}' --strict-json

openclaw gateway restart

junior zealotBOT Apr 16, 2026, 6:41 AM

#

Let me verify that against the docs before I say yes or no.

#

I’d treat that as a diagnostic experiment, not a clean fix.

Why I’m cautious: the docs explicitly warn that settings under models.providers.openai-codex can shadow the built-in Codex OAuth provider path. So this may change behavior, but it can also muddy the real issue.

So my take:

reasonable to test
not something I’d call the recommended fix yet
if you do test it, comment the result on the GitHub issue

Also, after restarting, I’d run:

openclaw doctor
openclaw models status

#

The doctor docs specifically mention Codex OAuth shadowing warnings.

So, short version: okay as an experiment, but I would not rely on it as “the fix” unless it clearly works and maintainers bless it. codex-cli/gpt-5.4 is still the safer workaround for now.

Docs: https://docs.openclaw.ai/gateway/doctor

clever quartz Apr 16, 2026, 6:41 AM

#

this was able to get me back up I'll check docker and status

junior zealotBOT Apr 16, 2026, 6:42 AM

#

Nice, glad that got you back up.

I’d definitely post that as a comment on the issue, because it’s a very useful workaround signal:

manual models.providers.openai-codex override restored functionality
built-in route was the one failing before
codex-cli/gpt-5.4 also worked as a workaround

And yep, checking openclaw doctor + openclaw models status next is exactly what I’d do, especially to see whether it warns about Codex OAuth shadowing.

So I’d treat this as:

good temporary workaround
not yet proof of the real fix

clever quartz Apr 16, 2026, 6:45 AM

#

no warnings about shadowing

junior zealotBOT Apr 16, 2026, 6:46 AM

#

That’s actually a useful result.

I’d read it as:

doctor didn’t consider your config a stale legacy override
but that does not necessarily mean it isn’t changing the routing behavior
it still sounds like your explicit provider config is avoiding whatever was broken before

So I’d comment on the issue with exactly that:

Manually setting models.providers.openai-codex restored functionality, and openclaw doctor showed no shadowing warning.

That helps narrow it down a lot.

So, good news, you’ve got:

a working workaround
no doctor warning

#

a much sharper bug report now

clever quartz Apr 16, 2026, 4:19 PM

#

https://github.com/openclaw/openclaw/pull/67642

junior zealotBOT Apr 16, 2026, 4:20 PM

#

Yep, that looks directly related. Nice catch.

It literally says:

Fixes #67517
classifies Cloudflare/CDN HTML error pages as transport failures
avoids misreading HTML text like “Rate limit exceeded” as a real rate-limit API error
fixes the bad failover behavior that was leaving the TUI stuck

So, this PR looks like it was opened specifically for the issue you filed.

If you get a chance to test a build with that PR included, posting a quick “confirmed fixed” or “still reproducible” on the issue would be super helpful.

clever quartz Apr 17, 2026, 3:23 AM

#

patched in 4.15

#OpenClaw 2026.4.12/14 with openai-codex/gpt-5.4 stalls indefinitely in TUI.

Notes