Repository navigation
[Bug]: Healthy ChatGPT Plus Codex login reports plan: null / quota: null and hides 5h/weekly usage #3644
Description
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
- On Windows 11, use a valid ChatGPT Plus Codex App login.
- Run OpenCodex 2.42.0.
- Execute:
ocx account list openai --quota --refresh --json- Observe that the main account is active and
needsReauthisfalse, butplanandquotaarenull. - Open the OpenCodex dashboard.
- 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: falseScreenshots 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.
Activity
github-actions commentedon Sep 5, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
[-][Bug][Codex account] `plan: null` / `quota: null` hides 5h and weekly usage for healthy ChatGPT Plus login[/-][+][Bug]: Codex main account reports `plan: null` / `quota: null`, hiding 5h and weekly usage[/+][-][Bug]: Codex main account reports `plan: null` / `quota: null`, hiding 5h and weekly usage[/-][+][Bug]: Healthy ChatGPT Plus Codex login reports `plan: null` / `quota: null` and hides 5h/weekly usage[/+]Ingwannu commentedon Sep 5, 2026
Thanks for splitting this from #3352. I checked the current
devsource (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 andneedsReauth: false; those fields do not mean the WHAM quota request succeeded. The CLI'snotes: []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 commentedon Sep 5, 2026
리뷰 · 우선순위 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으로 이미 다른 경로에서 풀렸습니다. 지금devHEAD(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”는 같은 신호가 아닙니다. CLInotes: []에도 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에서 WHAMresp.ok가 아니면 터미널 인증 실패일 때만 reauth를 찍고, 그 외에는EMPTY_MAIN_ACCOUNT_INFO만 반환한다. 자격은 살아 있는데 쿼터만 비는 상태가 여기서 나온다.라인 955-957 - fetch/JSON 예외도 같은 EMPTY로 떨어진다. 타임아웃·네트워크·프록시 실패가 CLI/대시보드에 카테고리 없이 묻힌다.
경로
src/codex/quota.tsparseUsageQuota- 200이어도rate_limit가 비면 quota가 null이 될 수 있다. “요청 실패”와 “빈 사용량 본문”을 구분하려면 상위 레이어에 결과가 필요하다.경로
src/cli/account-api.ts/ocx account list --quota --json-plan/quota만 내보내고 WHAM 실패 카테고리·quotaUnavailable사유를 거의 안 보여 줘서 재현 증거가 notes에 안 남는다.경로
guiQuotaBars / capacity - quota null이면 5h·weekly 막대가 사라지고 incomplete-coverage·uncalibrated-plan 경고가 뜬다. UI 버그라기보다 메타데이터 공백의 증상이다.메인테이너의 판단이 필요한 지점
auth-api주석의 admission/fresh 증거 규칙과 충돌하지 않게)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 commentedon Sep 5, 2026
Additional environment/reproduction details from the reporter:
/statuscorrectly shows both the 5-hour and weekly usage windows. (/usageshows historical/daily usage on this build;/statusis the command that exposes the current quota windows.)ocx account list openai --quota --refresh --jsonstill returnsplan: nullandquota: 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 previewdowngraded the install to2.40.0-preview.20260902. I restored2.42.0afterward. I therefore have not claimed a 2.43 preview reproduction yet; the currently published npmpreviewtag 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 commentedon Sep 5, 2026
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-accountquotaRefreshoutcome 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 commentedon Sep 5, 2026
The diagnostic slice is available in draft PR #3658 (
035dfc2c7). It exposes a fixedquotaRefreshcategory 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.
shortFisherman commentedon Sep 6, 2026
Correction to my previous retest note: I had the Clash Verge network mode wrong when I said the issue was resolved under system proxy + rule mode.
The successful OpenCodex 2.43.0 retest was actually performed with TUN mode enabled.
I have now switched Clash Verge back to my usual system proxy + rule mode, TUN disabled setup and re-ran:
On stable
2.43.0, the original issue reproduces again in this mode:{ "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": [] }So the current A/B observation on the same machine/account/version is:
plan: null,quota: null, and the quota bars disappear.Native Codex
/statuscontinues to show the quota windows correctly.This strongly suggests the remaining failure is network-path/proxy-related rather than an account entitlement problem. I am leaving #3644 open. The newer
quotaRefreshdiagnostic that landed after 2.43.0 should be particularly useful once a build containing it is available.Ingwannu commentedon Sep 6, 2026
Thanks for correcting the network mode. The same-machine/account/version A/B is useful: it points to a difference in the network path, but does not yet prove which HTTP/proxy operation failed. Please keep the report open rather than treating TUN as a general fix.
The bounded diagnostic from #3658 has now been carried and merged by @lidge-jun via #3693 (
71edeec8807d99e8e56a8c093f74da27d163d47a), and I verified that commit is in currentdev. The published latest release is stillv2.43.0as of this check, so your stable output withoutquotaRefreshis expected; reinstalling that release cannot expose the new field.Once a published build containing the merge is available, compare only the
quotaRefreshcategory and optional HTTP status under the same two network modes. No auth files, raw errors, or network captures are needed. I am not changing retry, credential, or system-proxy policy on the strength of the current A/B alone.shortFisherman commentedon Sep 7, 2026
Follow-up on
2.46.0with the newquotaRefreshdiagnostic:I now have a clean reproduction and a working configuration fix on the same machine/account.
Without TUN, using Clash Verge system proxy + rule mode
With TUN disabled and no explicit OpenCodex outbound proxy configured:
planandquotaare null and the quota bars disappear.With TUN enabled
The same command returns:
and the Plus plan/quota are populated.
Explicit OpenCodex system-proxy configuration
I then disabled TUN again, kept Clash Verge system proxy + rule mode enabled, added this top-level setting to OpenCodex config:
and restarted OpenCodex so it could re-read the Windows WinINET proxy at process start.
After that, with TUN still disabled, the same quota refresh succeeds:
and the Plus plan plus 5-hour/weekly quota metadata are populated again.
So the final A/B is:
timeoutok"proxy": "auto"+ service restart ->okThis appears consistent with the current documentation that the running OpenCodex service uses its own outbound proxy environment and that
"proxy": "auto"reads the Windows static WinINET proxy once at startup. From the reporter side, the original symptom is resolved with that configuration; I am happy for the issue to be closed if this is expected behavior.Ingwannu commentedon Sep 8, 2026
Thanks for the controlled A/B and for confirming that the original symptom is resolved. This matches the documented contract in reference/configuration/server.md: proxy="auto" reads the Windows static WinINET proxy once at process start; a proxy selected only in the interactive desktop environment is not automatically inherited by an independently running service. Existing proxy environment variables still take precedence, and PAC/WPAD is not covered by this mode.
Closing this original report based on your successful quotaRefresh=ok and restored plan/quota with the supported configuration. The diagnostic distinguished a transport timeout from authentication or account entitlement; no guessed plan/quota values or forced reauthentication were needed. This does not mean all null-quota cases share this cause. A recurrence with a different diagnostic category or the documented proxy configuration already applied should be reported separately with only redacted status categories and runtime versions.