Constantly reporting "Needs re-authentication" and does not provide the full model catalog

[smileBeda]

Client or integration

Codex CLI

Area

Platform (Windows / macOS / Linux)

Summary

I installed it and in the dashboard it says my OpenAI gpt account needs attention > needs re-authentication even if I authenticated several times and clearly can use it OpenAI models in the codex cli even if proxied over open codex.

What is worse is that all the "special" models are gone from the picker (daybreak blue, for instance).

I must be doing something wrong, I assume, since I cannot find any similar report here, however, not even gpt itself could figure it out, hence I am here asking...

Thanks!

Reproduction

Simply install opencodex and open the dashboard is literally enough.
Or, do above and then logout/relogin with the codex gpt account
Or, add a new account in the open codex dashboard and log in to it via dashboard...

Version

opencodex 2.33.0

Operating system

macOS Tahoe 26.5.2 (25F84)

Provider and model

gpt/openai

Logs or error output

Screenshots and supporting files

No response

Redacted configuration

Checks

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

[lidge-jun]

리뷰 · 우선순위 44 / 80

설명: 이 이슈는 대시보드가 OpenAI gpt 계정에 Needs attention 과 Needs re-authentication 을 계속 보여 주고, 피커에서 daybreak blue 같은 특별 모델이 빠진다는 보고다. 작성자는 smileBeda 이다. 라벨은 bug, catalog, platform 이다. 보고 버전은 opencodex 2.33.0 이다. 운영체제는 macOS Tahoe 다. 지금 CURRENT dev HEAD 는 ab63ded 이다. package.json 은 아직 2.32.1-preview.20260825 다. 이번 시간 origin/dev 는 안 움직였다. 본문에 로그와 설정이 비어 있다. 재현은 설치 후 대시보드만 열면 된다고 적혀 있다. 구현 풀은 없다. 내가 머지하지 않고 구현하지 않는다.

HEAD 에서 그 문구는 실제로 있다. gui/src/i18n/en.ts 1079줄 Needs attention, 1136줄 Active account needs re-authentication, 1173줄 modelsNeedsReauth 안내가 있다. gui/src/provider-workspace/usage.ts 159-182줄 buildAttentionItems 는 activeNeedsReauth 가 켜진 ready 행을 주의 목록에 넣는다. gui/src/provider-workspace/catalog.ts 255-274줄 applyActiveAccountReauth 는 섹션을 옮기지 않고 태그만 붙인다. 그래서 프록시로 모델이 되어도 대시보드 카드는 재인증을 요구할 수 있다. 서버 쪽 needsReauth 는 src/codex/auth-api.ts 277줄과 oauth/store 쪽에서 자격 없음, 쿼ota 401, 런타임 마크로 켜진다.

특별 모델이 빠진 것도 HEAD 와 맞물린다. src/codex/catalog/native-models.ts 5-10줄 ACCOUNT_GATED_NATIVE_OPENAI_MODELS 에 gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-daybreak-blue-latest 가 있다. src/codex/catalog/metadata.ts 424-426줄 nativeModelRows 는 cachedAvailableAccountGatedNativeModels 가 확인한 뒤에만 게이트 모델을 넣는다. src/codex/model-entitlements.ts 318-330줄은 계정별 확인 캐시가 살아 있고 confirmed 일 때만 그 아이디를 반환한다. 재인증 상태면 라이브 명단을 못 받아서 데이브레이크가 피커에서 사라질 수 있다. 일반 모델은 설정 목록이나 정적 목록으로 남을 수 있어서, 본문이 말한 프록시는 되는데 특별 모델만 없다 와 맞다.

다만 증거는 약하다. 로그가 비어 있고, redacted 설정도 비어 있다. 재인증이 진짜로 꼬였는지, 계정 자격이 원래 데이브레이크를 안 주는지, 메인 계정과 풀 계정이 어긋났는지 구분이 안 된다. 보고 버전 2.33.0 은 CURRENT dev 패키지 글자 2.32.1-preview.20260825 와 다르다. 배포본과 HEAD 가 어긋날 수 있다. types.ts 와 config.ts 가르기와는 무관하다. 프리뷰 배포가 아니다. 2464 2568 1049 2612 2210 2641 을 다시 열거나 댓글 달지 말 것.

경로/심볼 - gui/src/i18n/en.ts 1136줄 Active account needs re-authentication 문구가 본문과 같다
라인 159-182 - gui/src/provider-workspace/usage.ts 가 activeNeedsReauth 를 주의 목록에 넣는다
라인 255-274 - gui/src/provider-workspace/catalog.ts 는 재인증 태그만 붙이고 섹션은 유지한다
라인 277 - src/codex/auth-api.ts needsReauth 는 자격 없음이나 쿼ota 401 이나 런타임 마크로 켜진다
라인 5-10 - src/codex/catalog/native-models.ts 게이트 집합에 daybreak blue 가 있다
라인 424-426 - src/codex/catalog/metadata.ts 게이트 모델은 엔타이틀먼트 확인 뒤에만 보인다
라인 318-330 - src/codex/model-entitlements.ts 확인 캐시가 없으면 특별 모델이 빠진다
이슈 본문 - 로그와 설정이 비어 있어 원인 한 줄을 아직 못 고른다

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

• 지금 코드 버그로 볼지, 계정 상태 진단 이슈로 볼지. 지금은 진단이 먼저다
• 재인증이 끈질기면 어떤 로그를 더 받을지. ocx account 상태, needsReauth 원인, /models 응답이 필요하다
• 데이브레이크 숨김이 정상 게이트인지 버그인지. 자격이 없으면 숨기는 편이 맞다
• 같은 보고가 이미 있는지. 지금 열린 중복은 바로 안 보인다. 닫지 말 것
• 구현 풀을 지금 받을지. 로그 없이 받지 말 것

너의 추천
이 이슈는 연다. 닫지 말 것. 작성자에게 대시보드 Accounts 화면의 재인증 이유, ocx account 목록, needsReauth 가 켜진 계정 아이디, 같은 시각의 서버 로그, redacted 프로바이더 설정을 부탁한다. 코드상으로는 끈질긴 needsReauth 표시와 게이트 모델 숨김이 이미 연결되어 있다. 로그가 오기 전에는 구현 풀을 받지 않는다. 라벨은 그대로 둔다. 프리뷰 배포가 아니다. 내가 머지하지 않는다.

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

[smileBeda]

🤪

I do not fully understand - "ask the user why the log in loop happens"?!
That is why I am here

It literally goes like this:

1. go to http://localhost:10100/#providers

2. Click provider

3. Click big white fat button "re-authenticate"

Nothing. It kind of suggests I should re-authenticate through the app, which I do not use. I use the cli, So I re-authenticate in the cli... which does no difference

The models work - but not all models appear (daybreak is lost)
The dashboard keeps telling me I am not authenticated and no usage is logged neither.

Token expired — sign in again via Codex App login
So this proxy here requires me to use the app?!

Even worse, trying to edit the settings always ends in provider openai must equal the canonical built-in provider seed

[smileBeda]

Even if I add a second account (which then offers me a log in in the proxy gui) I still do not get the models I otherwise have access to.

No models are discovered for this provider in the GUI

lol

[Ingwannu]

Thanks — the new screenshots make the failure mode much clearer. You are not required to install or use Codex Desktop. In this UI, “Codex App login” is the internal label for the main ~/.codex/auth.json credential slot, which is shared with Codex CLI; the wording is misleading.

I traced the current dev flow and confirmed two separate behaviors:

1. For the canonical OpenAI/Codex provider, the large Re-authenticate button on the Overview page only switches to the Accounts tab. It does not launch a login for the main credential slot.
2. If the main slot was marked needsReauth, running codex login again for the same ChatGPT account does not by itself clear that in-memory mark. The account-identity reconciliation compares the physical account id, so a new token for the same id is not treated as an account transition. Today the mark is cleared only after an explicit successful account refresh (GET /api/codex-auth/accounts?refresh=1, exposed as Refresh quota on the Accounts page).

The provider openai must be the canonical built-in provider error is unrelated and expected: openai is a reserved built-in row and must not be edited as an ordinary custom provider.

After codex login, could you please run these two secret-free checks and paste the output?

curl -sS "http://localhost:10100/api/codex-auth/accounts?refresh=1" \
  | jq '[.accounts[] | {id, isMain, hasCredential, needsReauth, health, plan}]'

curl -sS "http://localhost:10100/v1/models" \
  | jq '[.data[].id | select(test("daybreak|gpt-5.6-(sol|terra|luna)"))]'

Please do not include tokens or auth.json. If the first command changes the main row to hasCredential: true / needsReauth: false and the gated models return, that confirms the stale same-account re-login path. If the account becomes healthy but the second list stays empty — including for the added dashboard account — the remaining fault is the account-scoped entitlement discovery path and I will trace that separately.

I am keeping this issue open. Regardless of the result, the current “Re-authenticate” action is not an adequate recovery flow for the main CLI-owned slot; we should not close this as user error.

[smileBeda]

curl -sS "http://localhost:10100/api/codex-auth/accounts?refresh=1" \
  | jq '[.accounts[] | {id, isMain, hasCredential, needsReauth, health, plan}]'
jq: error (at <stdin>:0): Cannot iterate over null (null)

bedas@apollo .codex % curl -sS "http://localhost:10100/v1/models" \
  | jq '[.data[].id | select(test("daybreak|gpt-5.6-(sol|terra|luna)"))]'
[]

All you need to replicate this issue is a GPT account, codex CLI, and the opencodex server running.
Its immediately visible as issue, and even if you connect a second pool account, which actually lets you authenticate within the proxy, the issue persists (both):

• main row will say needs re-authentication but has no way of re-authenticating
• any model that is not hardcoded into the gpt provider (such as daybreak) is stripped from the available models (even if the pool account is set to priority one and has access to the model)

[smileBeda]

I have a patch for this issue ready, and will PR it in short, if that is OK with you

[smileBeda]

#2793

[lidge-jun]

Fixed on dev by commit ca8fd60 (PR #2847), which narrowly reimplements @smileBeda's #2793.

OpenCodex now admits a caller-owned Codex bearer on the native-main path, so a keyring-managed Codex install works. Previously only file-backed credentials were admitted, which is why you saw a constant "Needs re-authentication" together with an incomplete model catalog.

Caller-supplied credentials are scoped to the request: they get a bearer-derived process-local identity, are never persisted, and cannot own or mutate the file-backed account's health, quota, affinity, or re-auth state. That isolation came out of independent security review — the first implementation let an invalid caller token mark the operator's own account as needing reauthentication.

Verified with tests/codex-auth-context.test.ts (65 pass), tests/server-auth.test.ts (86 pass) including 401/403/429/quota-header and transient-500 isolation cases, and tests/reasoning-replay-identity.test.ts (12 pass), all driven RED first.

This PR targeted dev, so GitHub did not auto-close the issue — closing manually.