[Bug]: Healthy ChatGPT Plus Codex login reports `plan: null` / `quota: null` and hides 5h/weekly usage

[shortFisherman]

Client or integration

OpenCodex dashboard

Area

Authentication and account pool

Summary

A healthy ChatGPT Plus Codex App login is recognized by OpenCodex as active and not needing reauthentication, but ocx account list openai --quota --refresh --json reports both plan: null and quota: null for the __main__ account.

As a result, the dashboard no longer shows the 5-hour or weekly quota bars and instead reports incomplete-coverage / uncalibrated-plan warnings.

This is the separate account/quota issue requested by the maintainer when closing #3352. The GPT-5.6 entitlement/catalog problem from that issue was fixed independently by #3460.

Reproduction

1. On Windows 11, use a valid ChatGPT Plus Codex App login.
2. Run OpenCodex 2.42.0.
3. Execute:

ocx account list openai --quota --refresh --json

4. Observe that the main account is active and needsReauth is false, but plan and quota are null.
5. Open the OpenCodex dashboard.
6. Observe that the 5-hour and weekly quota bars are missing and coverage/plan warnings are shown.

Observed output:

{
  "accounts": [
    {
      "provider": "openai",
      "type": "codex",
      "id": "__main__",
      "label": "Codex App login",
      "email": "Codex App login",
      "plan": null,
      "active": true,
      "needsReauth": false,
      "priority": 0,
      "paused": false,
      "quota": null
    }
  ],
  "notes": []
}

Dashboard symptoms:

• 5-hour quota bar is missing
• weekly quota bar is missing
• Incomplete coverage: 1 account excluded
• warning that one account is on an uncalibrated plan and is counted at the baseline seat weight

Version

2.42.0

Stable 2.43.0 has not been released at the time of filing. If a 2.43 preview/dev build is the recommended reproduction target, I can retest there.

Operating system

Windows 11

Provider and model

OpenAI / ChatGPT Plus Codex App login (__main__). This bug concerns account plan/quota metadata rather than a specific model.

Logs or error output

ocx account list openai --quota --refresh --json
# returns plan: null and quota: null while active: true and needsReauth: false

Screenshots and supporting files

The dashboard omits the 5-hour and weekly quota bars and shows incomplete-coverage / uncalibrated-plan warnings.

Redacted configuration

{
  "provider": "openai",
  "account": "__main__",
  "type": "codex",
  "active": true,
  "needsReauth": false,
  "plan": null,
  "quota": null
}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

Additional context

The maintainer noted in #3352 that the separate plan: null / quota: null observation comes from the /backend-api/wham/usage path in src/codex/auth-api.ts and is independent of the GPT-5.6 model roster/entitlement gate.

The current CLI output does not expose a WHAM status/error category. If there is a specific diagnostic command or log to capture that category, please point me to it and I can post a redacted result.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[Ingwannu]

Thanks for splitting this from #3352. I checked the current dev source (cfe95eea0): this is a valid diagnostic gap, but the report does not yet identify the upstream failure.

In src/codex/auth-api.ts, fetchMainAccountInfoWhileOwned() returns empty plan/quota metadata after a non-successful WHAM response or a fetch/JSON exception. listCodexAuthAccountsSnapshot() can still report a credential present and needsReauth: false; those fields do not mean the WHAM quota request succeeded. The CLI's notes: [] does not expose that failure category either. So the reported combination is possible without an invalid login, and it is independent of model-catalog entitlement.

The narrow fix to investigate is an explicit, sanitized quota-refresh outcome (HTTP status or timeout/network/invalid-response category), rather than guessing a plan, treating unknown quota as zero, or forcing reauthentication. Any reuse of older metadata must remain tied to the same account/credential and must not count as fresh quota evidence for account admission.

For now, please confirm whether the running OCX service and your interactive shell use the same Windows user/profile, whether a VPN/proxy/TUN is involved, and whether native Codex itself currently shows its usage windows. If existing diagnostics contain the WHAM failure, share only its status/error category—not auth.json, tokens, account identifiers, full response bodies, or a raw HAR. There is no dedicated WHAM error field in this CLI output to ask you to retrieve yet. Keeping this open; neither a fix nor a successful reproduction of your exact Windows failure is being claimed.

[lidge-jun]

리뷰 · 우선순위 61 / 80

설명

이 이슈는 ChatGPT Plus Codex App 로그인(__main__)이 살아 있고 needsReauth도 false인데, ocx account list openai --quota --refresh --json이 plan: null과 quota: null을 돌려주고 대시보드에서 5시간·주간 막대가 사라지는 문제를 말합니다. 닫힌 #3352에서 메인테이너가 “별도 계정/쿼터 이슈”로 분리하라고 한 바로 그 축이고, GPT-5.6 카탈로그/권한 쪽은 #3460으로 이미 다른 경로에서 풀렸습니다. 지금 dev HEAD(cfe95eea0, package 2.43.0)에서도 이 동작은 그대로 설명됩니다. src/codex/auth-api.ts의 fetchMainAccountInfoWhileOwned()가 https://chatgpt.com/backend-api/wham/usage를 호출하고, 응답이 실패하거나 예외가 나면 EMPTY_MAIN_ACCOUNT_INFO(email/plan/quota 모두 null)를 돌려줍니다. 반면 계정 목록 DTO는 로컬 자격 증명이 있고 재인증 플래그가 없으면 active: true, needsReauth: false를 유지할 수 있습니다. 즉 “로그인 OK”와 “WHAM 사용량 조회 OK”는 같은 신호가 아닙니다. CLI notes: []에도 WHAM HTTP 상태·타임아웃·파싱 실패 같은 카테고리가 없어서, 지금 JSON만으로는 왜 null인지 구분할 수 없습니다. 대시보드 쪽은 gui/src/components/QuotaBars.tsx와 capacity 집계(src/providers/codex-capacity.ts, ProviderCapacityQuota.tsx)가 quota가 없으면 막대를 숨기고 incomplete-coverage / uncalibrated-plan 경고를 띄우는 현재 설계와 맞습니다. 리포터 버전은 2.42.0이고 안정 2.43.0은 아직 출시 전이라, 재현은 preview/dev 빌드로 맞춰 보는 편이 좋습니다. Ingwannu 댓글이 이미 핵심을 짚었습니다. 수정 방향은 “plan을 추측하거나 null quota를 0으로 채우거나 강제로 reauth 시키기”가 아니라, 같은 계정/자격에 묶인 안전한 진단 결과(상태 카테고리)를 노출하는 쪽이어야 합니다.

라인 904-912 - src/codex/auth-api.ts에서 WHAM resp.ok가 아니면 터미널 인증 실패일 때만 reauth를 찍고, 그 외에는 EMPTY_MAIN_ACCOUNT_INFO만 반환한다. 자격은 살아 있는데 쿼터만 비는 상태가 여기서 나온다.
라인 955-957 - fetch/JSON 예외도 같은 EMPTY로 떨어진다. 타임아웃·네트워크·프록시 실패가 CLI/대시보드에 카테고리 없이 묻힌다.
경로 src/codex/quota.ts parseUsageQuota - 200이어도 rate_limit가 비면 quota가 null이 될 수 있다. “요청 실패”와 “빈 사용량 본문”을 구분하려면 상위 레이어에 결과가 필요하다.
경로 src/cli/account-api.ts / ocx account list --quota --json - plan/quota만 내보내고 WHAM 실패 카테고리·quotaUnavailable 사유를 거의 안 보여 줘서 재현 증거가 notes에 안 남는다.
경로 gui QuotaBars / capacity - quota null이면 5h·weekly 막대가 사라지고 incomplete-coverage·uncalibrated-plan 경고가 뜬다. UI 버그라기보다 메타데이터 공백의 증상이다.

메인테이너의 판단이 필요한 지점

• CLI/API에 넣을 WHAM 결과 카테고리의 최소 집합(예: http-status / timeout / network / invalid-json / empty-rate-limit / ok)을 어디까지 공개할지
• 캐시된 이전 plan/quota를 같은 credential generation에 한해 보여줄지, 아니면 null을 유지하고 “fresh 실패”만 표시할지 (auth-api 주석의 admission/fresh 증거 규칙과 충돌하지 않게)
• Windows에서 서비스 프로세스와 대화형 셸이 다른 사용자/프로필·VPN/TUN을 쓰는지 리포터 확인을 먼저 받을지, 아니면 진단 필드부터 넣고 재현을 돌릴지
• 2.42.0 재현만으로 충분한지, 아니면 dev/2.43 preview 재테스트가 머지 전 필수인지

너의 추천
이슈는 bug/account-pool로 열어 두고, 추측 plan 채우기나 null→0·강제 reauth PR은 받지 않는다. 다음 단계는 (1) 리포터에게 같은 Windows 프로필·VPN 여부·네이티브 Codex 사용량 창 표시 여부를 확인받고, (2) fetchMainAccountInfoWhileOwned / account-list JSON에 민감정보 없는 WHAM 결과 카테고리 필드를 추가하는 작은 진단 PR을 받은 뒤, (3) 그 카테고리로 실제 실패 원인을 본 다음에야 복구/캐시 정책을 고친다. #3352·#3460과 다시 묶지 말 것.

이 댓글은 grok-bot이 작성했습니다

[shortFisherman]

Additional environment/reproduction details from the reporter:

• The running OCX service and the interactive PowerShell shell use the same Windows user/profile. I verified the listener on port 10100 and the process owner; they resolve to the same account (case-only differences in display).
• Network setup: Clash Verge system proxy enabled, rule mode enabled, TUN / virtual adapter mode disabled. No TUN is involved in this reproduction.
• With OpenCodex stopped/bypassed, native Codex /status correctly shows both the 5-hour and weekly usage windows. (/usage shows historical/daily usage on this build; /status is the command that exposes the current quota windows.)
• On OpenCodex 2.42.0, ocx account list openai --quota --refresh --json still returns plan: null and quota: null.

I also attempted to retest on the npm preview channel as suggested, but the published dist-tags currently resolve to:

{
  "preview": "2.40.0-preview.20260902",
  "latest": "2.42.0"
}

So ocx update --tag preview downgraded the install to 2.40.0-preview.20260902. I restored 2.42.0 afterward. I therefore have not claimed a 2.43 preview reproduction yet; the currently published npm preview tag does not point to a 2.43 build.

I can retest on 2.43 preview/dev once there is a recommended published build or explicit install method. I will not post auth.json, tokens, account identifiers, full WHAM response bodies, or raw HAR data.

[Ingwannu]

Thanks for the additional checks. Same Windows profile and working native quota windows narrow the investigation; they do not yet distinguish OCX's WHAM HTTP, proxy/network, or response-decoding failure. Also, your preview-tag result means it is not a valid 2.43 reproduction target—please do not downgrade again for this issue.

I am preparing a narrow diagnostic patch against current dev: expose a bounded main-account quotaRefresh outcome in the existing account API and opt-in CLI quota JSON. It will report only a fixed category and, for HTTP failures, the numeric status. No tokens, account identifiers, raw errors or response bodies will be added. Authentication, quota admission, retry behavior, cached values and plan selection will remain unchanged. This first patch will make the failure actionable; it will not claim to fix the underlying Windows connectivity problem.

[Ingwannu]

The diagnostic slice is available in draft PR #3658 (035dfc2c7). It exposes a fixed quotaRefresh category and an HTTP status when applicable, without copying raw response/error material or changing authentication, quota freshness, cache policy, or routing.

Verification: 21 focused tests pass, TypeScript passes, the privacy scan passes, and the documentation build produces 425 pages. Full-suite/exact-head CI and independent review remain pending. It is not merged or released, so please do not reinstall from the preview tag for this patch yet.

Keeping #3644 open: the diagnostic gap is addressed in the draft, but the underlying failure on your Windows/proxy setup still needs a categorized observation after a reviewed build is available.