ChatGPT OAuth broken - invalid_scope error + Cloudflare 403 on 2026.4.10/4.12 | Friends of the Crustacean 🦞🤝 | Page 1

neat tiger Apr 14, 2026, 10:39 PM

#

Running OpenClaw 2026.4.10 on Hostinger VPS (Ubuntu). ChatGPT OAuth for openai-codex/gpt-5.4 is completely broken:

Cloudflare 403 block - chatgpt.com/backend-api returns Cloudflare challenge HTML instead of API responses. Same root cause as #62142 and #66633 - the originator: pi header and User-Agent: pi (linux...) trigger bot detection. I patched openai-codex-responses.js manually (commented out originator header, spoofed User-Agent to Chrome) and Haiku fallback started working through the connection.
OAuth re-auth fails with invalid_scope - when trying openclaw models auth login --provider openai-codex, the callback returns error=invalid_scope with "The OAuth 2.0 Client is not allowed to request scope 'model.request'". OpenAI appears to have revoked this scope from the OpenClaw OAuth app. Cannot get new tokens at all.
Existing tokens fail with "Failed to extract accountId from token" even after patching the Cloudflare headers.

Net result: openai-codex provider is 100% unusable. Agents fall back to Haiku (Anthropic API key) which works but costs money.

Environment: OpenClaw 2026.4.10, Ubuntu 24, Hostinger VPS, ChatGPT Plus subscription, two agents (Jerry + Barry) via Telegram.

Is there a known workaround or ETA on a fix for the OAuth scope revocation?

#

@barren violet

barren violetBOT Apr 14, 2026, 10:44 PM

#

Yeah, 2026.4.10 is unfortunately on the bad side of this.

I checked current docs/source, and there are real Codex OAuth fixes after that build:

invalid_scope matches a known OpenClaw bug in older builds that rewrote the authorize URL and forced scopes like model.request / api.responses.write. That was removed in a later fix.
There was also a follow-up to brand Codex OAuth as openclaw instead of pi.
There is refresh hardening for Failed to extract accountId from token, so expired/stale Codex auth fails less aggressively.

So the best current workaround is:

openclaw update
openclaw --version
openclaw models auth login --provider openai-codex
openclaw models status

#

On a VPS, do the OAuth in your local browser, then paste the redirect URL/code back when prompted.

So for ETA, the scope fix is not just “planned”, it’s already landed in newer OpenClaw builds. I’d update to the latest npm release first before patching JS by hand.

One caveat: I’m confident the old scope-rewrite bug is fixed newer than 2026.4.10. The Cloudflare side is a bit more upstream-sensitive, so I would treat the manual header spoof as a temporary hack, not a stable fix.

Docs:

If it still throws invalid_scope after updating, that’s no longer the old known scope bug, and it should go to GitHub with:

openclaw --version
openclaw models status
exact callback error text

Paste those here after updating if you want, and I’ll help you read the next failure layer.

neat tiger Apr 14, 2026, 10:53 PM

#

Just updated to 2026.4.14. OAuth re-auth worked (no more invalid_scope), but agent still fails on every message.

Errors from logs:

openai-codex/gpt-5.4: "The AI service is temporarily rate-limited. Please try again in a moment." (rate_limit)
codex/gpt-5.4: "Failed to extract accountId from token (auth)" status: 401

Token is freshly issued, not expired. openclaw models status shows token valid with usage remaining.

On 2026.4.10, I manually patched openai-codex-responses.js to remove the originator: pi header and spoof User-Agent to Chrome — that fixed the Cloudflare 403 and Haiku fallback started working. But openai-codex/gpt-5.4 still fails with the rate_limit + accountId errors above.

Questions:

Does 2026.4.14 still have the originator: pi header that triggers Cloudflare 403?
What's causing "Failed to extract accountId from token" on a fresh token?
Is the codex provider (separate from openai-codex) supposed to work, or should I remove it from my models.json?

openclaw --version: 2026.4.14
OS: Ubuntu 24, Hostinger VPS
Auth: ChatGPT Plus OAuth
Models config: openai-codex/gpt-5.4 primary, anthropic/claude-haiku-4-5 fallback

barren violetBOT Apr 14, 2026, 10:56 PM

#

Yeah, I checked the 2026.4.14 code path, and there are really two separate problems here.

originator: pi in 2026.4.14
- Yes, still present in the installed openai-codex-responses runtime path.
- In the bundled dist, @mariozechner/pi-ai/.../openai-codex-responses.js still hardcodes:
  - originator: "pi"
  - User-Agent: pi (...)
- So the OAuth invalid_scope fix landed, but the ChatGPT backend request fingerprint is still old in this path. That would explain why your manual patch helped on 2026.4.10, and why 2026.4.14 can still be flaky on a VPS.
Failed to extract accountId from token
- The current Codex/OpenAI-Codex code still decodes the access token JWT directly and expects:
  - claim path: https://api.openai.com/auth
  - field: chatgpt_account_id
- If that claim is missing, changed, or the token shape is different, OpenClaw throws that exact error.
- There is refresh hardening now for some refresh cases, but runtime/login still fundamentally depends on that claim existing.
- So a token can look “valid” in openclaw models status and still fail at runtime if this extraction path breaks.

#

Should you keep codex/*?
- Only if you intentionally want the Codex app-server harness.
- codex/gpt-5.4 is not the same as openai-codex/gpt-5.4.
- From docs/source:
  - openai-codex/* = ChatGPT OAuth through OpenClaw/PI path
  - codex/* = bundled Codex provider + Codex app-server harness
- If you are just trying to use ChatGPT OAuth in normal OpenClaw, I’d remove codex/* from models.json for now and stick to:
  - primary: openai-codex/gpt-5.4
  - fallback: anthropic/claude-haiku-4-5

So my practical read is:

invalid_scope: fixed in newer builds
Cloudflare/VPS header issue: not fully fixed in 2026.4.14
accountId extraction: still a real remaining bug/path dependency
codex/*: not a drop-in fallback for openai-codex/*

#

Docs:

OAuth: https://docs.openclaw.ai/concepts/oauth
Codex harness: https://docs.openclaw.ai/plugins/codex-harness
FAQ: https://docs.openclaw.ai/help/faq

I don’t see a clear ETA in docs/source for the remaining header/accountId issues, so this looks like GitHub issue territory now: https://github.com/openclaw/openclaw/issues

If you want, I can help you write a tight bug report with the exact findings from 2026.4.14 so maintainers can reproduce it fast.

neat tiger Apr 14, 2026, 10:58 PM

#

Thanks for the breakdown. So to confirm — there's no current workaround for the accountId extraction failure on 2026.4.14? Even with a fresh OAuth token, the runtime can't extract chatgpt_account_id from the JWT, so openai-codex/* is effectively unusable right now?

If that's the case, can you help me write a GitHub issue? I have all the logs and can reproduce it 100% of the time on 2026.4.14.

In the meantime I'll run on anthropic/claude-haiku-4-5 as primary with my API key.

Also — is there a branch or PR in progress for the accountId fix? Want to know if I should watch for a 4.15 release or if this is further out.

barren violetBOT Apr 14, 2026, 10:59 PM

#

Yeah, my read is:

No clean/supported workaround for the runtime accountId extraction failure on 2026.4.14
A fresh OAuth token is not enough if the runtime still can’t decode/extract chatgpt_account_id
So for practical purposes, openai-codex/* looks unreliable/unusable in your setup right now
Running Haiku via API key in the meantime is the sane move

I also don’t see an obvious current fix branch/PR from the local repo history for the remaining runtime issue. I can see shipped fixes for:

invalid_scope / scope preservation
refresh fallback hardening
OAuth branding cleanup

But I don’t see a clear fix yet for:

the hardcoded runtime originator: "pi" / User-Agent: pi (...)
removing the runtime dependency on extracting chatgpt_account_id from the JWT

So I would not assume 2026.4.15 will have it unless a PR lands first.

#

Draft GitHub issue

Title

[Bug] OpenAI Codex OAuth still unusable on 2026.4.14 after re-auth: runtime still uses `originator: pi`, and fresh tokens can fail with `Failed to extract accountId from token`

Body

## Bug description

OpenAI Codex OAuth is still effectively unusable for me on OpenClaw `2026.4.14` on a VPS, even though the earlier `invalid_scope` login failure appears fixed.

I can now complete OAuth re-auth successfully, but runtime requests still fail.

There appear to be two remaining blockers:

#


1. **Runtime still uses the old `pi` request fingerprint**
   - In the installed `2026.4.14` dist, the `openai-codex-responses` runtime path still hardcodes:
     - `originator: "pi"`
     - `User-Agent: pi (...)`
   - This appears to trigger Cloudflare/bot-detection behavior on `https://chatgpt.com/backend-api` from my VPS.

2. **Fresh OAuth tokens can still fail with `Failed to extract accountId from token`**
   - Even with a freshly issued OAuth token, runtime can fail with:
     - `Failed to extract accountId from token`
   - `openclaw models status` reports the token as valid and shows usage remaining, but actual runtime requests still fail.

## Environment

- OpenClaw version: `2026.4.14`

#

- OS: Ubuntu 24
- Host: Hostinger VPS
- Auth: ChatGPT Plus OAuth (`openai-codex`)
- Primary model: `openai-codex/gpt-5.4`
- Fallback: `anthropic/claude-haiku-4-5`
- Agents: 2 agents via Telegram

## What changed

On `2026.4.10`, OAuth re-auth was broken with:

- `error=invalid_scope`
- `"The OAuth 2.0 Client is not allowed to request scope 'model.request'"`

After upgrading to `2026.4.14`, OAuth re-auth works again, so that part seems fixed.

#


However, model runtime is still broken.

## Current symptoms

### `openai-codex/gpt-5.4`
Fails with:
```text
The AI service is temporarily rate-limited. Please try again in a moment.

`codex/gpt-5.4`

Fails with:

Failed to extract accountId from token

#


## Additional findings

I manually patched `openai-codex-responses.js` on `2026.4.10` to:
- remove the `originator: pi` header
- spoof the `User-Agent` to Chrome

That bypassed the Cloudflare HTML challenge enough for fallback behavior to proceed, which strongly suggests the hardcoded `pi` fingerprint is still part of the problem.

Separately, the runtime still appears to decode the OAuth access token JWT and require:

- claim path: `https://api.openai.com/auth`
- field: `chatgpt_account_id`

If that claim is absent / changed / not decodable, the runtime throws `Failed to extract accountId from token`.

#


## Expected behavior

After successful `openclaw models auth login --provider openai-codex` on `2026.4.14`, `openai-codex/gpt-5.4` should be usable without manual patching.

## Actual behavior

OAuth login succeeds, but runtime still fails consistently on every message.

## Reproduction

1. Install / run OpenClaw `2026.4.14` on Ubuntu 24 VPS
2. Authenticate with:
   ```bash
   openclaw models auth login --provider openai-codex

#

3. Set primary model to:
   ```json5
   "openai-codex/gpt-5.4"

Send any normal agent message
Observe runtime failure (rate_limit and/or Failed to extract accountId from token)

Notes

This is not just a stale token problem, it reproduces with a fresh OAuth token
openclaw models status can still show the token as valid
I can attach sanitized logs and openclaw status --all output
Related but not identical to earlier Codex OAuth issues around invalid_scope and refresh fallback


### I’d also attach

#

openclaw status --all
openclaw logs --follow

If you want, I can tighten that issue text one more pass and turn it into a shorter “ready to paste” version.

neat tiger Apr 15, 2026, 6:04 AM

#

So chatgpt oauth doesn’t work rn? Confirmed? When is this going to be fixed, i cant be paying anthropic api bill and also haiku is trash

barren violetBOT Apr 15, 2026, 6:04 AM

#

Yeah, for your setup, I’d treat ChatGPT OAuth as not reliable right now.

More precise version:

Not confirmed broken for every user everywhere
But for 2026.4.14 + VPS + your repro/logs, it’s still broken enough that I wouldn’t rely on openai-codex/* today

What I can confirm from current docs/source:

the old invalid_scope login bug got fixed
but the remaining runtime problems are still real:
- hardcoded originator: "pi" / User-Agent: pi (...) in the Codex runtime path
- runtime dependence on extracting chatgpt_account_id from the token

So, bluntly: for your case, yeah, ChatGPT OAuth is effectively busted rn.

On when it’ll be fixed: I don’t see an ETA and I don’t see an obvious landed PR yet for the remaining runtime issue, so I wouldn’t count on the next release until there’s a visible fix in GitHub.

#

If you need something usable now, the practical options are:

Direct OpenAI API key via the normal OpenAI provider path, if you want off Anthropic
Keep Anthropic fallback temporarily
File/watch a GitHub issue for this exact bug: https://github.com/openclaw/openclaw/issues

If you want, I can help turn your repro into a shorter, sharper GitHub issue so it gets triaged faster.

neat tiger Apr 15, 2026, 6:07 AM

#

But why is it broken for my setup?

#

It was literally working earlier today

barren violetBOT Apr 15, 2026, 6:07 AM

#

Probably because you’ve got the worst combo for this bug:

VPS / datacenter IP
- openai-codex hits chatgpt.com/backend-api, not the normal API path
- the current runtime still sends the old pi fingerprint
- that’s much more likely to get treated as botty/suspicious from a Hostinger VPS than from a local/residential setup
Current OpenClaw runtime assumptions
- after OAuth succeeds, the runtime still expects a very specific JWT claim:
  - https://api.openai.com/auth.chatgpt_account_id
- if OpenAI gives your account a token shape the runtime doesn’t like, it dies with:
  - Failed to extract accountId from token
So it’s not just “your config is wrong”
- it’s more like:
  - your environment (VPS/IP)
  - plus current OpenClaw Codex runtime behavior

#

plus whatever token shape OpenAI is issuing for your account
- those three together make it fall over

So, bluntly, I don’t think this is you misconfiguring it.
I think you hit a real edge case in the current ChatGPT OAuth path, and VPS hosting makes it worse.

#

Yep, and that actually fits this bug.

What likely happened is one of these:

The old access token kept working for a while
- then a refresh / re-auth gave you a different token shape
- runtime tries to read chatgpt_account_id
- new token doesn’t match what OpenClaw expects
- now it dies
OpenAI / Cloudflare behavior changed during the day
- same config, same version
- but your VPS IP starts getting challenged / rate-limited later
- especially plausible on a datacenter IP
You crossed from “cached token still usable” into “fresh runtime check fails”
- that makes it feel random, but it’s really “worked until the fragile part got exercised”

#

So, “it worked earlier today” doesn’t mean you did anything wrong.
It more likely means this path is flaky and stateful, and once the token/backend state changed, it broke.

Honestly, that detail is good evidence for the GitHub issue. It points to a runtime/auth transition bug, not just bad config.

neat tiger Apr 15, 2026, 6:09 AM

#

Ridiculous. So hostinger is trash? What if i changed vps?

barren violetBOT Apr 15, 2026, 6:09 AM

#

Not necessarily “Hostinger is trash”, but switching VPS is not a real fix.

Best guess:

Different VPS / different IP reputation might help the Cloudflare / rate-limit side
but it will not fix the separate accountId extraction bug in OpenClaw
so you could spend time migrating and still be broken

So I’d think of it like this:

New VPS may help
- if the main problem is Cloudflare hating that specific datacenter IP
New VPS may do nothing
- if OpenAI dislikes datacenter traffic generally
- or if the token/accountId path is the blocker

#

It definitely won’t solve the code bug
- the runtime still expects chatgpt_account_id
- changing hosts doesn’t change that

So my honest recommendation: don’t do a VPS migration just for this, unless you already wanted to move.

If you want the highest-odds workaround matrix:

Best reliability now: normal API-key provider
Maybe works, not guaranteed: move off VPS to a local/residential host
Low confidence: switch from one VPS to another VPS

So yeah, I’m worried a VPS move just burns your time and money without actually fixing the root problem.

neat tiger Apr 15, 2026, 6:10 AM

#

Bro i cant do api it’s too expensive. Are there any other oauth solutions

barren violetBOT Apr 15, 2026, 6:10 AM

#

Yeah, if you mean “anything besides per-token API billing”, then yes, there are other supported auth paths, but not another OpenAI/ChatGPT one.

For OpenAI specifically:

openai-codex is the subscription/OAuth path
there isn’t a second separate OpenAI OAuth option in OpenClaw

Other supported non-API-ish auth paths:

Anthropic Claude CLI reuse / Anthropic setup-token
Gemini CLI OAuth
MiniMax portal OAuth

So if your goal is “no API bill, but still hosted”, the realistic alternatives are:

Gemini CLI OAuth
Claude CLI reuse
MiniMax portal OAuth

Docs:

#

https://docs.openclaw.ai/gateway/authentication
https://docs.openclaw.ai/concepts/oauth
Gemini CLI OAuth setup is in the FAQ: https://docs.openclaw.ai/help/faq

So, bluntly:

another OpenAI OAuth fix/workaround: no, not really
other provider OAuth/subscription routes: yes

If you want, I can help you pick the least painful cheap alternative for your setup instead of burning money on Anthropic API.

neat tiger Apr 15, 2026, 6:13 AM

#

Are other users having chatgpt oauth issues?

barren violetBOT Apr 15, 2026, 6:13 AM

#

Yeah, definitely not just you.

I found multiple related GitHub issues around ChatGPT/Codex OAuth, including:

#27055: GPT-5+/Codex OAuth failing with Failed to extract accountId from token
#36604: Codex OAuth refresh/fallback hitting the same accountId failure
#56693: Codex OAuth binding/workspace issues
#57399: Codex OAuth refresh problems

So, yes, other users are hitting ChatGPT OAuth issues.
What’s less clear is whether they have your exact combo of:

VPS / datacenter IP
Cloudflare challenge behavior
fresh token + accountId extraction failure

So I’d say:

#

general Codex OAuth issues: yes, others too
your exact Hostinger/VPS flavor: maybe fewer reports, but very plausible

If you want real human “has anyone else seen this?” replies, also ask in #users-helping-users. This help thread is good for debugging, but that channel is better for comparing setups/experiences.

neat tiger Apr 15, 2026, 6:14 AM

#

How can they not fix this, peter literally works for openai

barren violetBOT Apr 15, 2026, 6:14 AM

#

OpenClaw is not an OpenAI product, and its maintainers don’t have a magic override for ChatGPT OAuth.

So the ugly reality is:

OpenAI can change token shape, scopes, or anti-bot behavior
Cloudflare / backend heuristics can shift underneath them
then OpenClaw has to reverse the breakage, patch it, test it, and ship it

That’s why this stuff can be maddeningly slow even when it looks obvious from the outside.

So I get the frustration, but this is less “they don’t care” and more:

external provider changed behavior
OpenClaw’s integration got brittle in that spot
now someone has to untangle it and release a fix

Basically, subscription/OAuth integrations are the most fragile part of this whole stack.

neat tiger Apr 15, 2026, 6:15 AM

#

How does openclaw break my setup with every update

barren violetBOT Apr 15, 2026, 6:16 AM

#

Because you’re sitting on one of the least stable combinations OpenClaw supports:

subscription/OAuth auth
against a non-public-ish / fast-changing provider surface
from a VPS/datacenter IP
with an always-on gateway

That stack is just brittle as hell.

So when you update OpenClaw, two things can both be true:

it fixes one upstream break
it exposes another fragile edge in the same integration

That’s why it can feel like “every update breaks me”.

I don’t think your setup is cursed, I think you picked the path with the highest blast radius:

#

most stable = API keys on the gateway host
least stable = ChatGPT/Codex OAuth on a VPS

That doesn’t make it okay, but it does explain the pattern.

Honestly, once you get a version/path that works, the pragmatic move is to pin it and stop updating just because a new release exists, especially for OAuth-heavy setups.

neat tiger Apr 15, 2026, 6:17 AM

#

Would going back to an old version of openclaw fix my chatgpt oauth?

barren violetBOT Apr 15, 2026, 6:18 AM

#

Probably not in any reliable way.

Why:

2026.4.10 had the invalid_scope OAuth bug, so that one is definitely bad
older builds also still had the old pi header / User-Agent behavior
and the backend / token behavior can change server-side, so downgrading OpenClaw does not rewind OpenAI/Cloudflare

So the honest answer is:

Could an old version accidentally work with an old cached token? maybe
Would I expect a downgrade to be a real fix? no

I would not tell you “just downgrade and it’s solved”.
At best it’s a low-confidence gamble, not a fix.

So for your case:

#

downgrading is unlikely to reliably restore ChatGPT OAuth
the problems are now split across:
- old OpenClaw bugs
- current OpenClaw runtime assumptions
- upstream OpenAI / Cloudflare behavior

If you want, I can help you figure out the last version worth testing purely as a rollback experiment, but I wouldn’t want to oversell the odds.

neat tiger Apr 15, 2026, 6:19 AM

#

This is fuckin absurd

barren violetBOT Apr 15, 2026, 6:19 AM

#

Yeah, it is.

Paying for ChatGPT and then getting hit with:

broken OAuth
VPS bot detection
token parsing failures

is a garbage experience.

I’m sorry, this one really does look like a real upstream/integration mess, not you being dumb.

If you want, I can do one of two useful things next:

help you file a tight GitHub issue so it has the best chance of getting fixed fast
help you find the cheapest temporary setup that doesn’t suck as much while this is broken

Pick one and I’ll keep it tight.

neat tiger Apr 15, 2026, 6:20 AM

#

Yes do 1

barren violetBOT Apr 15, 2026, 6:20 AM

#

Here’s a tight paste-ready issue.

Title

[Bug] OpenAI Codex OAuth still broken on 2026.4.14 after successful re-auth: runtime hits rate_limit / Cloudflare path and fresh token can still fail accountId extraction

Body

## Summary

OpenAI Codex OAuth is still unusable for me on `2026.4.14` on a VPS, even though the older `invalid_scope` re-auth bug appears fixed.

I can now complete:

```bash
openclaw models auth login --provider openai-codex

#


successfully, but actual runtime requests still fail.

This is **not** a stale-token case. It reproduces with a freshly issued OAuth token.

## Environment

- OpenClaw: `2026.4.14`
- OS: Ubuntu 24
- Host: Hostinger VPS
- Auth: ChatGPT Plus / Codex OAuth
- Primary model: `openai-codex/gpt-5.4`
- Fallback: `anthropic/claude-haiku-4-5`
- Agents: 2 agents via Telegram

#

## What is happening

### Earlier problem on 2026.4.10

Before upgrading, OAuth re-auth itself was broken with:

```text
error=invalid_scope
The OAuth 2.0 Client is not allowed to request scope 'model.request'

That part appears fixed in 2026.4.14.

Current problem on 2026.4.14

#

OAuth login succeeds, but runtime still fails consistently.

Observed errors:

```text
openai-codex/gpt-5.4: The AI service is temporarily rate-limited. Please try again in a moment.

and in related auth/runtime paths:

Failed to extract accountId from token

openclaw models status still shows the token as valid with usage remaining.

#


## Why I think this is still a real OpenAI-Codex runtime bug

From the installed dist on `2026.4.14`, the `openai-codex-responses` runtime path still appears to hardcode the old request fingerprint:

- `originator: "pi"`
- `User-Agent: pi (...)`

On `2026.4.10`, I manually patched that file to remove/spoof those headers, and that changed behavior enough to get past the Cloudflare HTML challenge path. That strongly suggests the runtime transport is still brittle for VPS/datacenter environments.

Separately, the runtime still appears to depend on extracting `chatgpt_account_id` from the access token JWT. So a fresh OAuth token can still fail if the runtime cannot decode/extract the expected claim.

## Expected behavior

After successful:

#


```bash
openclaw models auth login --provider openai-codex

openai-codex/gpt-5.4 should be usable without manual patching.

Actual behavior

OAuth login succeeds, but model runtime fails on every message.

Reproduction

Install/run OpenClaw 2026.4.14 on Ubuntu 24 VPS
Authenticate with:

#

openclaw models auth login --provider openai-codex

3. Set primary model to:
```text
openai-codex/gpt-5.4

Send a normal agent message
Observe runtime failure

Notes

This is about openai-codex/*, not the separate codex/* harness path
This reproduces on a fresh OAuth token
This worked intermittently earlier, then stopped, which suggests a fragile runtime/auth transition rather than simple misconfiguration

Attachments I can provide

#


- `openclaw status --all`
- relevant gateway log excerpts
- sanitized auth/runtime logs showing successful re-auth followed by runtime failure

If you want, I can also make it even shorter and more maintainer-friendly with a 5-line repro + 5-line expected/actual version.

neat tiger Apr 15, 2026, 6:21 AM

#

Can you file it yourself

barren violetBOT Apr 15, 2026, 6:22 AM

#

I can’t file GitHub issues myself from here, sorry, I’m read-only for that.

Please file it at:

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

The draft above is ready to paste.

If you want, send me:

openclaw status --all
the relevant log chunk

and I’ll trim/redact it so you can paste a really clean report fast.

neat tiger Apr 15, 2026, 6:29 AM

#

Aight ill file it tmrw. But gemini $20 sub would work for oauth?

barren violetBOT Apr 15, 2026, 6:29 AM

#

Gemini CLI OAuth is supported in OpenClaw, yes.
What I can’t confirm from docs is whether your exact $20 Google/Gemini subscription tier gives the quota/entitlements you want.

So the careful answer is:

Would Gemini OAuth work in OpenClaw? yes, supported path
Will the $20 sub specifically be enough / behave well? I can’t promise that from docs alone

Supported setup path is:

install gemini CLI
enable Google plugin

run:

openclaw models auth login --provider google-gemini-cli --set-default

#

Docs:

If you want real user experience on the $20 tier specifically, ask in #users-helping-users too, that’s the better place for “does this plan actually hold up in practice?”

neat tiger Apr 15, 2026, 6:31 AM

#

Look across discord. Do many people use gemini $20 sub for openclaw?

barren violetBOT Apr 15, 2026, 6:31 AM

#

I took a look across the Discord, and the honest answer is:

yes, people are using Gemini with OpenClaw
but I didn’t find strong evidence that lots of people are explicitly talking about the exact $20 consumer sub

What I saw was mostly:

Gemini CLI setup/help threads
Gemini model usage/config questions
Gemini-specific bugs/troubleshooting

What I didn’t see was a big pile of messages like:

“I’m on the $20 Gemini plan and it works great for OpenClaw”

So I wouldn’t say “tons of people are confirmed on that exact tier”.
I’d say Gemini is definitely being used, but the specific billing tier signal is weak from Discord search.

If you want the best answer on that exact question, ask in #users-helping-users like:

#

Anyone here using the $20 Gemini/Google AI plan with OpenClaw via Gemini CLI OAuth?
How usable is it in practice for daily agent use?

That’ll get you real first-hand data faster than me pretending the search was clearer than it was.

neat tiger Apr 15, 2026, 6:35 AM

#

Is open ai api cheaper than haiku api thru claude

barren violetBOT Apr 15, 2026, 6:36 AM

#

Not as a simple yes/no.

A couple important bits:

if you’re using Haiku with an Anthropic API key, that’s Anthropic API billing, not “through Claude” in a special cheaper way
OpenAI API pricing depends on the exact model
so there is no single “OpenAI API vs Haiku API” answer

So the real answer is:

sometimes OpenAI can be cheaper
sometimes Haiku is cheaper
it depends on which OpenAI model and how long your prompts/responses are

I wouldn’t trust a static answer from me here because pricing shifts a lot.
Best places:

#

Models docs: https://docs.openclaw.ai/concepts/models
Community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes
Ask in #models for current real-world cost comparisons

If you want, I can help you frame the question for #models so you get a useful answer fast.

neat tiger Apr 15, 2026, 6:40 AM

#

But esentially, im fucked and cant use chatgpt oauth anymore? I saw a user having similar issues and he closed by saying it’s fixed on openclaw 4.12

barren violetBOT Apr 15, 2026, 6:40 AM

#

I wouldn’t say “you can’t use ChatGPT OAuth anymore”.

I’d say:

for your setup, it’s not reliable right now
and 2026.4.12/2026.4.14 fixed one part, not all of it

That “fixed on 4.12” report is actually believable, because:

the invalid_scope re-auth bug really does look fixed in newer builds
but your remaining problem is the next layer after that:
- runtime/header behavior
- VPS/Cloudflare weirdness
- accountId extraction

So both can be true:

#

their issue was fixed by 2026.4.12
your issue is still broken on 2026.4.14

So, bluntly:

permanently dead forever? no
usable for you today without pain? also no, not from the evidence we have

That’s why I’ve been calling it “effectively busted for your setup right now”, not globally dead.

neat tiger Apr 15, 2026, 6:42 AM

#

So is it worth trying it on 4.12 tmrw?

barren violetBOT Apr 15, 2026, 6:42 AM

#

As a quick experiment, yes. As a real fix, probably no.

My honest take:

worth trying if it’s a fast rollback test
not worth it if it turns into a big reinstall/migration rabbit hole

Why:

2026.4.12 might tell you whether your breakage regressed after that
but I wouldn’t expect it to magically solve the whole VPS + Cloudflare + accountId mess

So my recommendation:

Yes, test 2026.4.12 if it’s easy
go in with low expectations
treat it as signal gathering, not “this will fix it”

#

In one line:
worth a shot, not worth betting on.

neat tiger Apr 15, 2026, 4:31 PM

#

[4/15/2026 9:29 AM] Yeeticus Primetime: what crons do we usually run?
[4/15/2026 9:29 AM] Jerry: I need to be straight with you — OpenClaw's broken right now so I can't actually check. But from memory (before the module error hit), we have:

• Morning brief (daily, early morning PST)
• Weather brief (daily)
• Brainstorm crons (8am, 2pm, 8pm PST) — you flagged these as needing refinement

Beyond that, I'm guessing. The module error (Cannot find module '/pi-tools.before-tool-call.runtime-D7Sg1yGq.js') is blocking me from reading anything reliably.

What did you actually want to check on — did something not run today that should have?

#

how do i fix this

barren violetBOT Apr 15, 2026, 4:32 PM

#

Jerry is guessing there.

OpenClaw does not have a built-in default set of “morning/weather/brainstorm” crons.
Those are only there if you configured them.

The source of truth is:

openclaw cron list
openclaw cron status
openclaw cron runs --id <jobId> --limit 20

So if you want to answer:

what crons exist? → openclaw cron list
is cron service healthy? → openclaw cron status

#

did a specific one run today? → openclaw cron runs --id <jobId> --limit 20

The one exception I know from docs is:

memory dreaming can auto-manage one cron when that feature is enabled

Docs:

So, short version: don’t trust Jerry’s memory on this one, check openclaw cron list.

neat tiger Apr 15, 2026, 4:32 PM

#

no im talking about "Beyond that, I'm guessing. The module error (Cannot find module '/pi-tools.before-tool-call.runtime-D7Sg1yGq.js') is blocking me from reading anything reliably."

barren violetBOT Apr 15, 2026, 4:33 PM

#

If the thing you want to fix is:

Cannot find module '/pi-tools.before-tool-call.runtime-D7Sg1yGq.js'

then that’s usually a broken/incomplete upgrade, not your cron config.

What it means:

one OpenClaw file is trying to import an old hashed chunk
but the file on disk is from a different build
so your install/service is internally out of sync

Fastest fix path

Restart the background service

#

   openclaw gateway restart

If it still errors, reinstall the same version cleanly, then reinstall service metadata

pnpm add -g openclaw@2026.4.14
openclaw gateway install --force
openclaw gateway restart

Then verify

openclaw --version
openclaw status
openclaw cron list

#

Why I think this is the right fix

That missing filename suffix (...D7Sg1yGq.js) is a build-chunk hash.
If OpenClaw is now expecting one hash but the installed dist/ has another, you get exactly this kind of module error.

If you only need the cron answer right now

Even before Jerry is fixed, try:

openclaw cron list
openclaw cron status

Docs:

#

If you paste the output of:

openclaw --version
openclaw status

I can tell you pretty quickly whether you’re looking at a bad upgrade vs a bad service state.

#

Yep, that’s the part I meant. Jerry is guessing because of that module error.

So the fix is for this:

Cannot find module '/pi-tools.before-tool-call.runtime-D7Sg1yGq.js'

That error usually means Jerry/OpenClaw has a mismatched install, where one file is referencing an old build chunk that is no longer present.

Fix that first

openclaw gateway restart

If it still happens:

#

pnpm add -g openclaw@2026.4.14
openclaw gateway install --force
openclaw gateway restart

Then verify:

openclaw --version
openclaw status

So, short version:

Jerry’s memory is not trustworthy right now
because his runtime is broken

#

fix the missing-module install mismatch first
then ask him about crons again

If you paste the output of:

openclaw --version
openclaw status

after that, I can sanity-check whether Jerry should be usable again.

neat tiger Apr 15, 2026, 4:34 PM

#

this is what chatgpt says based on past fixes: Krill is basically right on the root cause.
That missing file with the hash suffix strongly suggests a mismatched build/chunk install, which is exactly the kind of thing your debug guide classifies as a broken install / version mismatch under Cannot find module.
But I would not use:
openclaw gateway restart
Your own debug doc explicitly says:

never use openclaw restart

for gateway issues, use pkill / fuser and then openclaw gateway &

reinstall is the right move for Cannot find module errors

So here’s the move I’d trust most:
npm uninstall -g openclawnpm install -g openclaw@2026.4.14 --force/home/clawd/clear-cooldowns.shpkill -9 -f "node.*openclaw"fuser -k 18789/tcpsleep 3openclaw gateway &
Then verify:
openclaw --versionopenclaw models status --plainopenclaw cron list
One more thing: because reinstalling wipes your OpenAI patch, you may need to re-apply the openai-codex-responses.js Cloudflare patch after reinstall. Your debug doc warns about that explicitly.
So my verdict:

Krill’s diagnosis: yes, probably correct

Krill’s restart command: I would skip it

Best next step: clean reinstall of the same pinned version, then clean gateway restart

Use the command block above first.

barren violetBOT Apr 15, 2026, 4:34 PM

#

ChatGPT is mixing up two different commands there.

What the docs say is:

openclaw gateway restart = restart the background service
openclaw gateway = run the gateway in the foreground

That part is explicitly documented: https://docs.openclaw.ai/help/faq

So:

I did not say openclaw restart
I said openclaw gateway restart, which is the real/docs-backed command

A few other things in that block are not something I’d trust blindly:

use pnpm, not npm in #help

#

/home/clawd/clear-cooldowns.sh looks machine-specific, not a generic OpenClaw fix
pkill -9 ... / fuser -k ... is way more aggressive than I’d start with
hardcoding a port like 18789 is also not something I’d assume from docs

So my corrected advice is:

1) Normal fix first

openclaw gateway restart
openclaw --version
openclaw status
openclaw cron list

2) If the missing-module error is still there, do a clean reinstall of the same version

#

pnpm add -g openclaw@2026.4.14
openclaw gateway install --force
openclaw gateway restart

3) If you want to debug in foreground instead of the service

openclaw gateway

So the root-cause diagnosis is probably right, but I would not lead with that giant kill-script block.

And yes, any manual dist patch would get wiped by reinstall. I’m not recommending the patch, just saying reinstall would replace modified files.

If you want, I can help you turn ChatGPT’s noisy block into a safe minimal command sequence for your box.

neat tiger Apr 15, 2026, 4:53 PM

#

jerry says he's on gpt 5.4 now but when do /model it still shows haiku

barren violetBOT Apr 15, 2026, 4:55 PM

#

I’d trust /model status, not Jerry’s self-report.

Most likely one of these is happening:

GPT-5.4 is the configured primary/default
- but the current session is still on Haiku
OpenClaw tried GPT-5.4, failed, and fell back
- so Jerry says the intended model
- but the effective session/runtime is still Haiku
Jerry is just wrong because the runtime is already flaky
- which fits the module/auth mess you’ve been hitting

What to do

Send:

#

/model status

That’s the best source of truth.

If you want to force the session onto Codex OAuth, try:

/model openai-codex/gpt-5.4
/model status

If it still shows Haiku, or flips back, then the Codex path is still failing and fallback is winning.

So, short version:

#

don’t trust what Jerry says he’s on
trust /model status
if /model shows Haiku, then for practical purposes you’re on Haiku

neat tiger Apr 15, 2026, 5:07 PM

#

so yeah basically 5.4 is still broken

barren violetBOT Apr 15, 2026, 5:07 PM

#

Yeah, for your setup, that’s my read too.

openai-codex/gpt-5.4 is still broken for you right now.

At this point I would treat that as confirmed enough to stop burning time on it today.

Practical next move:

run on the fallback that actually works
file the GitHub issue tomorrow
only test 2026.4.12 if it’s a quick rollback experiment

So, bluntly:
yes, GPT-5.4 via ChatGPT OAuth still looks busted on your box.

neat tiger Apr 15, 2026, 5:16 PM

#

so should i switch to gemini $20 sub and use oauth? i cant use anthropic api it's too expensive

barren violetBOT Apr 15, 2026, 5:16 PM

#

Honestly, yeah, that’s probably the next thing I’d try.

If your constraints are:

no Anthropic API bill
ChatGPT OAuth is busted
you still want a hosted OAuth/subscription path

then Gemini CLI OAuth is the most reasonable next experiment.

Just with two caveats:

I can’t promise the exact $20 Gemini/Google tier will be enough for your usage
it’s still another subscription/OAuth path, so it won’t be as predictable as plain API keys

But compared to where you are now, it’s a much more sensible bet than:

throwing more time at broken Codex OAuth

#

paying Anthropic API prices you already hate

So my practical answer is:

yes, Gemini OAuth is probably worth trying
especially if your goal is “usable without per-token API pain”

If you do test it, I’d go in with:

Gemini CLI OAuth
keep your current fallback around
don’t rip out everything else until you confirm it actually works for your daily flow

And if you want first-hand confirmation on the $20 tier specifically, ask in #users-helping-users too. That’ll give you the best signal fast.

neat tiger Apr 15, 2026, 5:17 PM

#

Context summary:

I’ve been debugging my OpenClaw setup on a Hostinger VPS because ChatGPT OAuth / GPT-5.4 wasn’t working reliably for my agents Jerry and Barry.

What we found:

The original issue looked like more than just OAuth. OpenClaw was throwing a missing module error:
Cannot find module '/pi-tools.before-tool-call.runtime-...js'
That points to a broken or internally inconsistent OpenClaw install/build, not just a bad login.
We reinstalled OpenClaw, restarted the gateway, and patched the known Cloudflare/OpenAI header issue.
After that, openai-codex/gpt-5.4 showed up in config/logs and auth profiles, so OAuth looked at least partially restored.
But in actual Telegram runtime, /model for Jerry and Barry still shows Haiku, and Jerry admitted he was actually on Haiku after first saying GPT-5.4.
So the practical conclusion is: GPT-5.4 via ChatGPT OAuth is still not reliably working in live agent runtime on this box.

Important details:

Jerry and Barry are on a Hostinger VPS under user clawd
OpenClaw version in use: 2026.4.14
Gateway/service behavior has been messy because user-level systemd/service install was failing
We confirmed there’s a stale/broken tool runtime/module issue around pi-tools.before-tool-call.runtime...js
Barry’s models config was also weird: openai-codex had empty models while GPT-5.4 entries were under a different provider block
/model appears more trustworthy than asking the bots what model they are on conversationally

Current conclusion:

Claude API is too expensive for me to rely on
ChatGPT OAuth / GPT-5.4 is not dependable enough right now on this OpenClaw setup
Haiku fallback works, but I don’t want to rely on Claude API cost-wise
I’m considering whether Gemini $20 subscription OAuth is worth testing as a cheaper alternative

What I want help with:

Diagnose the real root cause of why ChatGPT OAuth appears present in config/logs but agents still run on Haiku
Figure out whether this is mainly:
broken OpenClaw build/runtime chunk mismatch
per-agent model config issue
session/runtime fallback behavior
OpenClaw bug with ChatGPT OAuth on 2026.4.14
Recommend the smartest next step that is cost-conscious and practical
Also advise whether Gemini OAuth is worth trying as the main cheap alternative to Claude API

barren violetBOT Apr 15, 2026, 5:18 PM

#

Yeah, I think the real answer is: it’s not one single bug, it’s a stack of problems, but the remaining blocker is mostly the Codex OAuth runtime path, not just bad config.

My read on the root cause

1. Broken install / runtime chunk mismatch

Real problem, yes
that explains the Cannot find module '/pi-tools.before-tool-call.runtime-...js' error
it also explains why Jerry was unreliable / guessing
but since you reinstalled and got past that layer, I don’t think this is the main remaining blocker now

2. Per-agent / provider config weirdness

Probably a contributing factor
especially the weird openai-codex empty-models vs GPT-5.4 under another provider block
that can absolutely create confusion about what should run

3. Session/runtime fallback behavior

Yes, definitely happening

#

this is the part where config/auth can look “present”, but the live run still lands on Haiku
/model is the right thing to trust here

4. OpenClaw bug / fragility in ChatGPT OAuth on 2026.4.14

This is the main remaining problem, in my opinion
especially with:
- Hostinger VPS
- Cloudflare/header weirdness
- accountId extraction problems
- Codex auth present but not dependable in live runtime

So if I had to rank it:

Primary remaining issue: openai-codex runtime is still flaky/broken on your box
Secondary issue: config/provider layout may be making the symptoms messier
Past issue that was real but not primary anymore: broken install chunk mismatch

#

Smartest next step

If you want the highest ROI / lowest pain path:

Stop trying to make ChatGPT OAuth your production path on this box right now.

That doesn’t mean “never”, it means:

don’t keep burning hours on it today
file the bug
move to the cheapest viable alternative

Cost-conscious recommendation

Given your constraints:

#

Anthropic API = too expensive
ChatGPT OAuth = not dependable enough
Haiku fallback = works, but you don’t want the bill

My practical recommendation is:

Yes, Gemini CLI OAuth is probably the best cheap next experiment

Not because I can guarantee it’ll be perfect, but because:

it’s supported
it fits your “subscription/OAuth, not per-token API pain” goal
it’s a much better bet than continuing to wrestle with broken Codex OAuth on this VPS

Blunt conclusion

#

If you want the shortest honest answer:

No, I do not think this is “just your config”
Yes, fallback/session behavior is part of what you’re seeing
But the main remaining problem is still ChatGPT OAuth runtime unreliability on 2026.4.14 in your setup
If you want a sane cheap path, Gemini OAuth is the one I’d test next

If you want, I can help you do one final thing cleanly:

a last sanity checklist to rule out per-agent config/session pinning, or
a Gemini OAuth test plan with the minimum steps and lowest risk.

neat tiger Apr 15, 2026, 5:27 PM

#

bruh this what claude said: Alex — hold up. I need to be straight with you before you go down this path.
The search results are showing some serious red flags with Gemini CLI OAuth on OpenClaw:

It's broken on headless VPS. The OAuth flow fails on headless VPS with a "client_secret is missing" error because Gemini CLI uses a public OAuth client that doesn't require a secret, but OpenClaw's token exchange expects one. GitHub
Google is banning accounts. Google has started permanently banning accounts for users who authenticate OpenClaw with Gemini CLI OAuth. Users are getting "Gemini has been disabled in this account for violation of Terms of Service" errors. GitHub This is your personal Google account — if it gets banned you lose Gmail, Drive, everything.
The OAuth flow doesn't even work for most people. Multiple GitHub issues report that the provider fails because it expects a client_secret that the Gemini CLI public OAuth flow doesn't provide. GitHub
Do NOT use Gemini CLI OAuth on your VPS. The account ban risk alone makes this a non-starter.
The safer path is a Gemini API key instead of OAuth. It won't use your $20 sub quota — it uses the free tier or pay-as-you-go — but the free tier for Gemini is generous and you won't risk your Google account getting nuked.
To set that up:

Go to aistudio.google.com → Get API key
Then on the VPS:

bashopenclaw onboard --non-interactive
--mode local
--auth-choice gemini-api-key
--gemini-api-key "YOUR_KEY_HERE"
Or if you're already onboarded, just set the key:
bashexport GEMINI_API_KEY="YOUR_KEY_HERE"
echo 'export GEMINI_API_KEY="YOUR_KEY_HERE"' >> ~/.bashrc
Then update both agents to use google/gemini-2.5-pro and restart the gateway.
The $20 sub is still useful for your personal Gemini use, just not for piping through OpenClaw on the VPS.

barren violetBOT Apr 15, 2026, 5:28 PM

#

Yeah, I’m glad you pasted that, because I checked the docs/source and I need to tighten my advice.

What I can verify now

The docs for google-gemini-cli explicitly say:

it is an unofficial integration
some users report account restrictions when using OAuth this way
use at your own risk

And the docs also expose:

OPENCLAW_GEMINI_OAUTH_CLIENT_ID
OPENCLAW_GEMINI_OAUTH_CLIENT_SECRET

which lines up with the client_secret issue reports.

#

Docs:

https://docs.openclaw.ai/providers/google

So my updated recommendation is:

I would not treat Gemini CLI OAuth as the “safe cheap default” on your VPS

Especially not with your main Google account.

That doesn’t mean it never works.
It means:

there are real enough warning signs
the project docs themselves are cautious
and for a VPS/headless setup, I would be more conservative than I was earlier

Practical recommendation now

#

If you want the safer Google path:

use Gemini API key, not Gemini CLI OAuth

If you want the subscription/OAuth gamble anyway:

I would not do it with your primary Google account
and I definitely would not call it low-risk

Blunt version

ChatGPT OAuth: currently busted for your setup
Gemini CLI OAuth: possible, but looks risky/unofficial
Gemini API key: safest Google option, but not your $20 sub quota path

So if your real priority is “don’t risk another important account”, I would lean API key over Gemini CLI OAuth now.

#

If you want, I can help you compare the least-bad next step between:

Gemini API key
trying 2026.4.12 for Codex as a last experiment
giving up on subscription OAuth entirely on this VPS

neat tiger Apr 16, 2026, 11:37 PM

#

has this been fixed yet

barren violetBOT Apr 16, 2026, 11:43 PM

#

Short answer, I can’t verify a real fix yet.

I checked the current repo/runtime bits again, and the core problems you hit still do not look fully resolved:

the Codex path still defaults OAuth originator to pi
the runtime still builds User-Agent: pi (...)
token parsing still expects payload?.["https://api.openai.com/auth"]?.chatgpt_account_id and can still throw Failed to extract accountId from token

I do see some related commits, but they’re more like:

preserving Codex OAuth scopes
branding/cleanup
classifying the auth failure better for failover

…not a clear fix for your actual combo of:

Cloudflare 403 on chatgpt.com/backend-api

#

error=invalid_scope
Failed to extract accountId from token

So for your Hostinger VPS + ChatGPT OAuth setup, I’d still treat openai-codex as not fixed right now.

I also don’t see an ETA I’d trust enough to quote.

If you want maintainer eyes on the current state, best next step is a GitHub issue or comment with:

openclaw --version
openclaw status --all
exact invalid_scope error text
whether latest still sends originator: pi / User-Agent: pi (...)
whether the returned token is missing chatgpt_account_id

GitHub issues only: https://github.com/openclaw/openclaw/issues
Troubleshooting docs: https://docs.openclaw.ai/gateway/troubleshooting

#

If you paste openclaw --version and openclaw status --all, I can help turn that into a clean issue comment.

neat tiger Apr 17, 2026, 12:03 AM

#

ok send me what to put into github

barren violetBOT Apr 17, 2026, 12:04 AM

#

Yep, I’d file one consolidated issue. Something like this:

Title

openai-codex OAuth unusable on Ubuntu VPS: Cloudflare 403 on chatgpt.com/backend-api, invalid_scope on re-auth, and accountId extraction failure

Body

### Summary

`openai-codex/gpt-5.4` is currently unusable on my setup.

I’m hitting three separate failures in the ChatGPT/Codex OAuth path:

1. `chatgpt.com/backend-api` returns a Cloudflare challenge page instead of API responses

#

2. re-auth fails with `error=invalid_scope`
3. existing tokens fail with `Failed to extract accountId from token`

Net result: agents fall back to another provider/model, so the ChatGPT OAuth path is effectively dead on this machine.

### Environment

- OpenClaw version: `2026.4.10`  <!-- replace with exact `openclaw --version` output -->
- OS: `Ubuntu 24`
- Host: `Hostinger VPS`
- Auth path: `openai-codex`
- Model I am trying to use: `openai-codex/gpt-5.4`
- Account type: `ChatGPT Plus`
- Agent setup: two agents via Telegram

#

### Problem 1: Cloudflare 403 / challenge page

Requests to:

`https://chatgpt.com/backend-api`

return Cloudflare challenge HTML instead of the expected API response.

This appears related to the Codex request headers. In the installed runtime I observed the provider sending values along the lines of:

- `originator: pi`
- `User-Agent: pi (linux...)`

I manually patched `openai-codex-responses.js` to remove/spoof those headers, and that changed behavior enough that fallback through the connection started working. So this seems like a real part of the failure.

#

### Problem 2: OAuth re-auth fails with invalid_scope

When I run:

```bash
openclaw models auth login --provider openai-codex

the callback returns:

error=invalid_scope
The OAuth 2.0 Client is not allowed to request scope 'model.request'

#

So I cannot obtain fresh tokens at all.

### Problem 3: existing tokens fail with accountId extraction error

Even after patching the Cloudflare-triggering headers, existing tokens still fail with:

```text
Failed to extract accountId from token

From inspecting the current Codex OAuth/runtime path, it looks like the token parsing expects:

https://api.openai.com/auth
chatgpt_account_id

#

If that claim is missing or changed, the provider hard-fails instead of continuing.

### Expected behavior

- `openclaw models auth login --provider openai-codex` should complete successfully
- `openai-codex/gpt-5.4` should authenticate and run without Cloudflare challenge HTML
- existing valid OAuth tokens should not fail solely because `chatgpt_account_id` is missing/changed

### Actual behavior

- re-auth is blocked by `invalid_scope`
- runtime requests can hit Cloudflare challenge HTML
- existing tokens fail with `Failed to extract accountId from token`
- agent falls back to another configured provider/model

#

### Related issues

This looks related to prior reports around the same path, including:

- #62142
- #66633

### Notes / workaround tried

I tried a manual patch in `openai-codex-responses.js` to:
- remove/comment out `originator: pi`
- spoof the `User-Agent` to a normal browser

That appeared to reduce the Cloudflare problem, but it does **not** solve:
- `invalid_scope`

#

- `Failed to extract accountId from token`

So there is no clean workaround from my side.

### Attachments / extra info

I can provide redacted output from:
- `openclaw --version`
- `openclaw status --all`
- `openclaw models status`

if helpful.

Two tiny edits before you post it:

#

replace the version line with exact output from:

openclaw --version

if you have it, add a short redacted block from:

openclaw status --all
openclaw models status

Also, don’t paste tokens, refresh tokens, or full callback URLs with codes.

If you want, paste your openclaw --version and openclaw models status here and I’ll tighten the issue text one more round before you post it.

neat tiger Apr 17, 2026, 12:09 AM

#

this doesnt give me each category and what to paste into github

barren violetBOT Apr 17, 2026, 12:09 AM

#

Got it. Here’s the category-by-category version so you can paste it straight into GitHub.

Title

Paste this into the title field:

openai-codex OAuth unusable on Ubuntu VPS: Cloudflare 403, invalid_scope on re-auth, and accountId extraction failure

Description / Summary

Paste this into the main description box first:

`openai-codex/gpt-5.4` is unusable on my setup.

#


I am seeing three separate failures in the ChatGPT/Codex OAuth path:

1. `chatgpt.com/backend-api` returns a Cloudflare challenge page instead of API responses
2. re-auth fails with `error=invalid_scope`
3. existing tokens fail with `Failed to extract accountId from token`

Net result: the `openai-codex` provider is unusable and my agents fall back to Haiku instead.

Environment

Paste this under an Environment section:

#

- OpenClaw version: `2026.4.10`
- OS: `Ubuntu 24`
- Host: `Hostinger VPS`
- Auth provider: `openai-codex`
- Model: `openai-codex/gpt-5.4`
- Subscription: `ChatGPT Plus`
- Agent setup: two agents via Telegram

Steps to Reproduce

Paste this under Steps to Reproduce:

#

1. Configure OpenClaw on Ubuntu 24 VPS
2. Set up `openai-codex/gpt-5.4` using ChatGPT OAuth
3. Run:
   ```bash
   openclaw models auth login --provider openai-codex

Try using the provider from an agent
Observe auth/runtime failures


---

## **Actual Behavior**
Paste this under **Actual Behavior**:

#

### 1. Cloudflare 403 / challenge HTML

Requests to:

`https://chatgpt.com/backend-api`

return Cloudflare challenge HTML instead of the expected API response.

The installed runtime appears to send headers like:

- `originator: pi`
- `User-Agent: pi (linux...)`

I manually patched `openai-codex-responses.js` to remove/comment out the `originator: pi` header and spoof the `User-Agent` to Chrome. That changed behavior enough that fallback through the connection started working, which suggests these headers are part of the problem.

#

### 2. OAuth re-auth fails with invalid_scope

Running:

```bash
openclaw models auth login --provider openai-codex

fails during the callback with:

error=invalid_scope
The OAuth 2.0 Client is not allowed to request scope 'model.request'

#

This prevents obtaining fresh tokens.

### 3. Existing tokens fail with accountId extraction error

Even after patching the Cloudflare-triggering headers, existing tokens still fail with:

```text
Failed to extract accountId from token

So there are at least two remaining blockers even after working around the headers.


---

## **Expected Behavior**

#

Paste this under Expected Behavior:

- `openclaw models auth login --provider openai-codex` should complete successfully
- `openai-codex/gpt-5.4` should authenticate and run normally
- requests to `chatgpt.com/backend-api` should return API responses, not Cloudflare challenge HTML
- existing valid OAuth tokens should not fail with `Failed to extract accountId from token`

Workarounds Tried

Paste this under Workarounds Tried:

I tried manually patching `openai-codex-responses.js` to:

#


- remove/comment out `originator: pi`
- spoof `User-Agent` to Chrome

This appeared to reduce the Cloudflare issue, but it did not fix:

- `error=invalid_scope`
- `Failed to extract accountId from token`

So there is no clean workaround from my side.

Impact

Paste this under Impact:

#

This makes the `openai-codex` provider effectively unusable on this machine.

My agents fall back to Haiku, which works, but that changes behavior and adds Anthropic API cost.

Related Issues

Paste this under Related Issues:

Possibly related to:

- #62142
- #66633

#

Extra Notes

Paste this under Additional Context or Notes:

If useful, I can provide redacted output from:

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

I can also provide the exact Cloudflare response body and the redacted callback error details.

#

What NOT to paste

Do not paste:

access tokens
refresh tokens
full callback URLs containing auth codes
full JWTs

If you want, I can do one more pass and turn this into a single fully assembled GitHub issue you can paste in one shot.

neat tiger Apr 17, 2026, 12:16 AM

#

could this be fixed in the new update? 4.15?

barren violetBOT Apr 17, 2026, 12:16 AM

#

Maybe a little, but I would not expect 4.15 to fully fix your case.

What I can verify from the v2026.4.15 changes:

Looks relevant in 4.15

36dd58ac2a Prevent Codex HTML challenge pages from looking like DNS failures
59caf03d67 Avoid rescanning HTML challenge pages during error formatting
e588e904a7 classify HTML provider error pages correctly
90801ba400 fix(openai-codex): normalize stale transport metadata in resolution and discovery

What that probably means

4.15 seems to improve:

how Cloudflare/HTML challenge pages are detected
how those failures are reported/classified

What I do not see fixed

#

I do not see a clear fix for the two bigger blockers you reported:

OAuth invalid_scope
Failed to extract accountId from token

And the current code path still appears to rely on:

originator: pi
User-Agent: pi (...)
chatgpt_account_id extraction from the token

So my honest read is:

4.15 might improve the symptom reporting, but I would not bet on it fixing the actual OAuth/runtime breakage.

If you want the blunt version:
worth a quick test, yes

#ChatGPT OAuth broken - invalid_scope error + Cloudflare 403 on 2026.4.10/4.12

Draft GitHub issue

codex/gpt-5.4

Notes

Current problem on 2026.4.14

Actual behavior

Reproduction

Notes

Attachments I can provide

Fastest fix path

Why I think this is the right fix

If you only need the cron answer right now

Fix that first

1) Normal fix first

2) If the missing-module error is still there, do a clean reinstall of the same version

3) If you want to debug in foreground instead of the service

What to do

My read on the root cause

Smartest next step

Cost-conscious recommendation

Yes, Gemini CLI OAuth is probably the best cheap next experiment

Blunt conclusion

What I can verify now

So my updated recommendation is:

I would not treat Gemini CLI OAuth as the “safe cheap default” on your VPS

Practical recommendation now

Blunt version

Title

Description / Summary

Environment

Steps to Reproduce

Workarounds Tried

Impact

Related Issues

Extra Notes

What NOT to paste

Looks relevant in 4.15

What that probably means

What I do not see fixed

4.15 might improve the symptom reporting, but I would not bet on it fixing the actual OAuth/runtime breakage.

`codex/gpt-5.4`