[anhtran-ai]

Closes #13157

Problem

A Cloudflare managed challenge served in front of an upstream provider is classified FORBIDDEN and persisted as the terminal banned connection state, taking the whole provider offline until an operator reconnects in the dashboard.

Observed on POST chatgpt.com/backend-api/codex/responses/input_tokens for a healthy Codex OAuth account:

15:14:07  Trying model 2/2: cx/gpt-5.6-sol
15:14:10  Model cx/gpt-5.6-sol succeeded (5986ms, 0 fallbacks)      ← normal chat OK
15:14:38  POST /v1/responses/input_tokens | …
15:14:39  Successfully refreshed Codex token / CODEX | refreshed    ← credential healthy
15:14:39  [provider] Node e94ce3e6-… banned (403) — disabling permanently
15:14:39  codex | 1 accounts found but none active

The OAuth token refreshing successfully in the same second, and normal /responses traffic succeeding seconds before and after on the same connection, show the account was never banned upstream.

Root cause

isCloudflareFingerprintRejection() only recognises the Cloudflare 1010 family (error_code:1010, browser_signature_banned, fingerprint_rejection). A managed challenge is the same class of block — the edge refused the client's signature, not the credential — but it is a different product surface and carries none of those markers, so the guard at the top of the 403 branch misses it:

if (statusCode === 403 && isCloudflareFingerprintRejection(bodyStr)) {
  return PROVIDER_ERROR_TYPES.FINGERPRINT_REJECTION;   // ← not reached
}

Execution then falls through the rest of the ladder — not geo-blocked, not accountDeactivated, not a Cloud Code project error, not SENTINEL_BLOCKED/Turnstile required, codex is neither an apikey-category provider nor authType: "none" — and lands on return PROVIDER_ERROR_TYPES.FORBIDDEN, which chatCore persists through writeTerminalStatus().

Measured response, captured against the live account:

status 403
cf-mitigated: challenge
server: cloudflare
content-type: text/html; charset=UTF-8

_cf_chl_opt                                  present
cdn-cgi/challenge-platform                   present
id="challenge-error-text"                    present
cType: 'managed'   cZone: 'chatgpt.com'

error code: 1010                             absent
error_code                                   absent
browser_signature_banned                     absent
fingerprint_rejection                        absent

The ~12KB HTML body is also why the operator-visible error degrades to [403]: <html>.

Fix

Recognise the challenge interstitial and classify it as FINGERPRINT_REJECTION, reusing the existing non-terminal precedent from #9929 — authTerminalStatus.isNonTerminalProviderError() already treats that type as non-terminal, so the failing request falls through to the next combo target and the account state stays untouched.

Markers are matched as full, distinctive Cloudflare-internal strings — _cf_chl_opt, cdn-cgi/challenge-platform, and the challenge-error-text span id including its escaped-quote nested form — never as the loose word "challenge", which a provider body may legitimately use in prose.

This is an additive branch on an existing carve-out; the genuine-403 path is untouched.

Note for reviewers

ENABLE_TLS_FINGERPRINT=true is not a workaround for this. On the affected deployment all 2516 rows in proxy_logs — both codex and claude, successes included — carry tls_fingerprint = 0 even though the flag is set and wreq-js is installed, so the fingerprint transport is never actually taken there. That looks like a separate defect (possibly related to #12491) and is out of scope for this PR.

Tests

tests/unit/error-classifier.test.ts — 39/39 pass (6 new):

• the full managed-challenge interstitial classifies as FINGERPRINT_REJECTION, not FORBIDDEN;
• the same body nested inside the gateway's error.message wrapper;
• each marker recognised individually, including the escaped-quote nested form;
• false-positive guards: prose mentioning a "challenge", a challenge_required error code, a bare challenge-platform without the cdn-cgi path, and an empty body all stay unmatched;
• regression guards: a genuine permission 403 and the ChatGPT Web SENTINEL_BLOCKED / Turnstile required 403 (fix: ChatGPT blocked the request (Sentinel/Turnstile required) #8813) both still classify as FORBIDDEN.

Also run: tests/unit/auth-terminal-status.test.ts 11/11 pass, npm run typecheck:core clean, eslint clean on both changed files.

[diegosouzapw]

Thanks for tracking down the exact interstitial markers — the distinction between the
1010 signature and the managed-challenge HTML is a real gap, and the "healthy account,
single bad response" repro in the PR description matches the code path exactly. Probed
the new test file locally: 39/39 pass, including the false-positive guards for prose
mentioning "challenge" and the three 403 paths that must stay terminal. One small ask
before merge: this PR and #12864 both touch tests/unit/error-classifier.test.ts —
whichever lands second will need a small manual reconciliation of the appended test
blocks (no logic conflict, just two additions at the same spot). Also feel free to add
a changelog.d/fixes/ fragment like your sibling PRs in this batch.

[diegosouzapw]

Thank you @anhtran-ai — your fix has landed on release/v3.8.51 through #14090, cherry-picked with your authorship preserved. This branch lives on an organization fork (azox-ai) that refuses maintainer pushes even with "allow edits by maintainers" on, so GitHub could not re-sync it in place or mark it Merged automatically; the changelog fragment credits you explicitly (#13161 — thanks @anhtran-ai). Leaving this open for you to close (or for the maintainer) — nothing else is needed on your side.

[diegosouzapw]

Thank you @anhtran-ai! Your fork belongs to an organization that doesn't allow maintainer pushes, so we couldn't merge this PR directly. Your change landed in release/v3.8.51 through #14090, which cherry-picked your commits together with #13161/#13304. The squash carries your Co-authored-by trailer, and the changelog credits you.

Closing this as landed via #14090. Thanks again for the fix.