Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
After upgrading from 2026.4.12 to 2026.4.14, every openai-codex/gpt-5.4 agent turn fails because chatgpt.com/backend-api/v1 returns a Cloudflare bot-mitigation challenge page (HTTP 403, cf-mitigated: challenge) instead of an API response, with the failure misreported in logs as "DNS lookup for the provider endpoint failed."
Steps to reproduce
- Run OpenClaw 2026.4.12 with openai-codex/gpt-5.4 as the primary model and confirm agent turns succeed.
- Upgrade to 2026.4.14 with
openclaw update. Do not change any config or re-authenticate.
- Send any message to an agent configured with openai-codex/gpt-5.4.
- Observe failure in the user journal:
journalctl --user -u openclaw-gateway -n 50 --no-pager
- Confirm chatgpt.com is reachable and the block is at the Cloudflare layer, not DNS:
curl -sI https://chatgpt.com/backend-api/v1
Returns: HTTP/2 403, cf-mitigated: challenge
Expected behavior
openai-codex/gpt-5.4 completes agent turns successfully using the stored ChatGPT OAuth token, as observed on 2026.4.12 with the same config and credentials.
Actual behavior
Every request fails. Gateway logs show:
[agent/embedded] embedded run agent end: isError=true model=gpt-5.4 provider=openai-codex error=LLM request failed: DNS lookup for the provider endpoint failed. rawError= <style global>body{font-family:Arial...
The rawError is a Cloudflare JS challenge HTML page, not a DNS failure. The DNS lookup succeeds; chatgpt.com resolves to Cloudflare IPs. The "DNS lookup failed" message is a misclassification (see #64092).
On the first retry the log reports "API rate limit reached" before switching to the DNS error on subsequent retries — both are misclassifications of the same Cloudflare 403 HTML response.
OpenClaw version
2026.4.14
Operating system
Ubuntu 24.04 / Linux 6.8.0
Install method
No response
Model
openai-codex/gpt-5.4
Provider / routing chain
openclaw -> openai-codex (chatgpt.com/backend-api/v1)
Additional provider/model setup details
- Auth method: ChatGPT OAuth (browser sign-in via
openclaw models auth login --provider openai-codex)
- Re-authenticating after the upgrade does not resolve the issue. The OAuth token is valid and not expired (~7 days remaining). The block is at the Cloudflare header-detection layer, not the token layer.
- Fallback provider zai/glm-5.1 is confirmed working on the same machine and same network, ruling out a general connectivity issue.
- Deployment: self-hosted headless server (no browser present at request time).
- Config: agents.defaults.model.primary = openai-codex/gpt-5.4, fallback = zai/glm-5.1.
Logs, screenshots, and evidence
Gateway log (redacted):
[gateway] agent model: openai-codex/gpt-5.4
[agent/embedded] embedded run failover decision: decision=surface_error reason=timeout from=openai-codex/gpt-5.4
[errors] Long error truncated: <html>
[agent/embedded] embedded run agent end: isError=true model=gpt-5.4 provider=openai-codex error=<html>...
[agent/embedded] embedded run agent end: 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"...
Root cause traced in installed package:
File: node_modules/@mariozechner/pi-ai/dist/providers/openai-codex-responses.js (~line 715)
function buildBaseCodexHeaders(initHeaders, additionalHeaders, accountId, token) {
...
headers.set("originator", "pi");
const userAgent = _os ? `pi (${_os.platform()} ${_os.release()}; ${_os.arch()})` : "pi (browser)";
headers.set("User-Agent", userAgent);
return headers;
}
Cloudflare detects `originator: pi` and `User-Agent: pi (linux ...)` as non-browser traffic and issues a 403 challenge. This is the same root cause documented in #62142. The distinction from prior reports is that 2026.4.12 was not affected — something in 2026.4.14 changed the request code path so that it now consistently triggers this block.
Confirmed with curl:
$ curl -sI https://chatgpt.com/backend-api/v1
HTTP/2 403
cf-mitigated: challenge
content-type: text/html; charset=UTF-8Impact and severity
Affected: all self-hosted deployments using openai-codex/gpt-5.4 as primary model on 2026.4.14, headless (no browser) environment.
Severity: blocks all agent workflow — primary model has 100% failure rate.
Frequency: every request, 100% reproducible since upgrading to 2026.4.14.
Consequence: agents produce no responses via any configured channel; fallback provider must be used as primary workaround.
Additional information
Last known good version: 2026.4.12
First known bad version: 2026.4.14
This is a distinct regression from #62142 (reported on 2026.4.5) and #64174 (reported on 2026.4.9). Those reports describe users who never had it working on recent versions. This report confirms 2026.4.12 works and 2026.4.14 does not, with no config changes between upgrades.
The 2026.4.14 release notes mention changes to Codex transport policy and transport-turn-state resolution. One of those changes likely shifted the request code path in a way that re-exposed the originator: pi / User-Agent: pi header issue for users who were unaffected on 2026.4.12.
Workaround: set agents.defaults.model.primary to a working provider (e.g. zai/glm-5.1) until fixed.
Related issues: #62142, #64174, #64092
Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
After upgrading from 2026.4.12 to 2026.4.14, every openai-codex/gpt-5.4 agent turn fails because chatgpt.com/backend-api/v1 returns a Cloudflare bot-mitigation challenge page (HTTP 403, cf-mitigated: challenge) instead of an API response, with the failure misreported in logs as "DNS lookup for the provider endpoint failed."
Steps to reproduce
openclaw update. Do not change any config or re-authenticate.journalctl --user -u openclaw-gateway -n 50 --no-pager
curl -sI https://chatgpt.com/backend-api/v1
Returns: HTTP/2 403, cf-mitigated: challenge
Expected behavior
openai-codex/gpt-5.4 completes agent turns successfully using the stored ChatGPT OAuth token, as observed on 2026.4.12 with the same config and credentials.
Actual behavior
Every request fails. Gateway logs show:
[agent/embedded] embedded run agent end: isError=true model=gpt-5.4 provider=openai-codex error=LLM request failed: DNS lookup for the provider endpoint failed. rawError= <style global>body{font-family:Arial...
The rawError is a Cloudflare JS challenge HTML page, not a DNS failure. The DNS lookup succeeds; chatgpt.com resolves to Cloudflare IPs. The "DNS lookup failed" message is a misclassification (see #64092).
On the first retry the log reports "API rate limit reached" before switching to the DNS error on subsequent retries — both are misclassifications of the same Cloudflare 403 HTML response.
OpenClaw version
2026.4.14
Operating system
Ubuntu 24.04 / Linux 6.8.0
Install method
No response
Model
openai-codex/gpt-5.4
Provider / routing chain
openclaw -> openai-codex (chatgpt.com/backend-api/v1)
Additional provider/model setup details
openclaw models auth login --provider openai-codex)Logs, screenshots, and evidence
Impact and severity
Affected: all self-hosted deployments using openai-codex/gpt-5.4 as primary model on 2026.4.14, headless (no browser) environment.
Severity: blocks all agent workflow — primary model has 100% failure rate.
Frequency: every request, 100% reproducible since upgrading to 2026.4.14.
Consequence: agents produce no responses via any configured channel; fallback provider must be used as primary workaround.
Additional information
Last known good version: 2026.4.12
First known bad version: 2026.4.14
This is a distinct regression from #62142 (reported on 2026.4.5) and #64174 (reported on 2026.4.9). Those reports describe users who never had it working on recent versions. This report confirms 2026.4.12 works and 2026.4.14 does not, with no config changes between upgrades.
The 2026.4.14 release notes mention changes to Codex transport policy and transport-turn-state resolution. One of those changes likely shifted the request code path in a way that re-exposed the originator: pi / User-Agent: pi header issue for users who were unaffected on 2026.4.12.
Workaround: set agents.defaults.model.primary to a working provider (e.g. zai/glm-5.1) until fixed.
Related issues: #62142, #64174, #64092