OpenAI account setup disappears when the built-in provider is missing

[apple-ouyang]

Problem

OpenAI account credentials can still exist while providers.openai is missing or disabled. In that state:

• Providers → Add Provider → Accounts does not show OpenAI because the list is derived only from configured forward providers.
• Codex Auth shows a dead-end “built-in OpenAI provider is not configured” message even though the account pool is still present.
• Requests fail with No enabled OpenAI provider for model ... and the GUI offers no direct recovery path.

On macOS with Clash fake-IP DNS, creating the canonical OpenAI preset can also be rejected because chatgpt.com resolves into 198.18.0.0/15, even after the request has passed the strict canonical OpenAI seed validation.

Observed on v2.7.39.

Expected behavior

• Always show OpenAI in the unified Accounts picker.
• If OpenAI is missing, create it from the existing canonical provider preset and then open the existing Codex account flow.
• If OpenAI is disabled, re-enable it without replacing its saved account mode or model settings.
• Offer the same recovery action directly on the Codex Auth page.
• Keep destination validation unchanged for custom providers; only the exact canonical built-in OpenAI seed should bypass fake-IP DNS rejection.

[Ingwannu]

Confirmed on current dev: the account data can survive while the canonical providers.openai entry is missing or disabled, but the unified Accounts picker and Codex Auth surface still do not provide a complete canonical recovery action. The exact built-in seed also needs a narrowly scoped fake-IP DNS exception without weakening destination checks for custom providers.

The previous draft #445 is closed; active PR #469 now tracks the recovery flow. I am keeping this issue open until that PR proves all three states with focused tests: missing provider creation, disabled provider re-enable without overwriting saved settings, and exact-canonical fake-IP handling.

[Ingwannu]

Resolved in #469, merged to dev as b59fc009d92810f22c8614f9e02d6471e432797d.

The merged implementation restores OpenAI setup from both Accounts and Codex Auth when the built-in provider is absent or disabled. Recovery is limited to the canonical openai-responses + forward-auth + Codex base URL shape; noncanonical rows remain blocked, saved mode/model settings are preserved on re-enable, and the Clash fake-IP allowance remains limited to benchmark answers while loopback, RFC1918, metadata, and mixed dangerous answers are rejected.

Verification on the exact merged head included 71 focused backend/policy/payload tests, 6 GUI recovery interaction tests, TypeScript typecheck, GUI lint, and all GitHub checks.

[WilliamLuuu]

Follow-up: re-adding a deleted built-in OpenAI provider still fails with paired IPv4/ULA IPv6 Fake-IP DNS in 2.41.0

I checked the closure of this issue and #469. The recovery button is present, so this is not a report that the original UI recovery work is missing. It is an additional DNS-answer shape that the recovery request still rejects. Related #2810 / #2842 addressed a different, explicit-zero IPv4-mapped IPv6 shape.

What happened / reproduction

Environment: OpenCodex 2.41.0, Windows 11, bundled Bun 1.4.0, OpenCodex dashboard.

1. Have a working native Codex application login.

2. Delete the built-in openai provider. This was the user-visible trigger; it was not established that the update itself deleted the provider.

3. On the affected network, chatgpt.com resolves to both:

   A     198.18.0.36
   AAAA  fdfe:dcba:9876::14
   

4. Open Codex Auth in the dashboard. The native main account is still recognized, and the page says the account remains available but OpenAI must be enabled.

5. Click Enable OpenAI. The dashboard only displays “Failed to enable the OpenAI provider.”

The user suspects router-side OpenClash in Fake-IP mode is producing the synthetic answers. The DNS results above were measured on the Windows client; the router configuration and the exact origin of the IPv6 prefix were not independently verified. Please do not treat that prefix as a documented default for every OpenClash deployment.

Exact failure

Replaying the dashboard's canonical preset request to POST /api/providers reproduced HTTP 400:

{"error":"baseUrl hostname chatgpt.com resolves to a private-network address (fdfe:dcba:9876::14); set allowPrivateNetwork:true only for intentionally local/self-hosted providers"}

The request contained only the built-in preset:

{
  "name": "openai",
  "provider": {
    "adapter": "openai-responses",
    "baseUrl": "https://chatgpt.com/backend-api/codex",
    "authMode": "forward",
    "codexAccountMode": "pool"
  }
}

Expected: recover the built-in OpenAI provider on this working proxy network, without changing DNS or unrelated provider credentials. Native account authentication was separately verified successfully; this particular failure occurs during provider creation, before model inference.

Locally tested solution direction

A narrowly scoped local compatibility patch restored the workflow. This is a proposed direction for maintainer review, not a suggestion to classify ULA IPv6 addresses as globally public or enable unrestricted private-network access:

• Retain the existing explicit Fake-IP opt-in and canonical built-in OpenAI checks.
• For this additional IPv6 form, require the exact HTTPS origin https://chatgpt.com, the standard port, no URL userinfo, and an actual IPv4 answer from 198.18.0.0/15 in the same DNS result set.
• Under those conditions only, accept the observed fdfe:dcba:9876::/48 IPv6 form. IPv6-mapped addresses or a misleading resolver family must not count as IPv4 evidence.
• Apply the same conditional treatment at provider configuration validation and DNS-resolved outbound validation. Continue checking every answer: mixed loopback, ordinary private, link-local or metadata results must still fail.
• Leave general IPv6 classification, literal-IP URLs, other origins, and callers without the opt-in unchanged. A maintainer-approved configurable representation may be preferable to baking in a deployment-specific prefix.

It would also help to show the sanitized backend validation reason in the dashboard instead of only the generic enable failure.

Verification

• Focused regression tests against the actual runtime module: 4 reproduced the failure before the patch; all 26 passed afterward. Coverage includes the reported pair, expanded IPv6 notation, strict origin/port checks, missing IPv4 evidence, misleading family values, literal IPs, and mixed unsafe answers.
• Validation with the client's real DNS answers passed without changing DNS.
• After restarting only OpenCodex, the original preset request returned 200, success: true, and catalog refresh committed, changed: true, degraded: false.
• GPT models reappeared, and the user confirmed the fix works in the dashboard.
• Other providers' API keys/key pools and account credential files were verified unchanged. No tokens, account identifiers, personal paths, or screenshots containing account data are included here.
• The full upstream test/typecheck suite was not run: this was a local repair of the published npm package, which did not include the complete repository test tooling.

Adding this evidence to the existing issue rather than opening a duplicate. Please reopen or split out the IPv6 follow-up if that fits the project's tracking process.