Repository navigation
[Bug][2.35][Codex App] Entitled GPT-5.6 Sol/Terra/Luna disappear from the native catalog #2886
Description
Activity
리뷰 · 우선순위 73 / 80
증상은 분명하다. ChatGPT Plus 계정이 네이티브 Codex에서는 GPT-5.6을 쓰고, OpenCodex 2.33.0에서도
gpt-5.6-sol/gpt-5.6-terra/gpt-5.6-luna가ocx models live에 보이며 Sol 요청이 성공한다. 같은 계정으로 2.35.0만 켜면 세 슬러그가 카탈로그와 Codex 피커에서 사라지고,ocx models enable은invalid model visibility target만 낸다. 계정은plan=plus,needsReauth=false, WHAM 200이다. 권한 부족이 아니라 OpenCodex가 “없다”고 잘못 접는 쪽에 가깝다. 지금devHEAD(8621acb87, 패키지 2.36.0)에도 #2550이 넣은 계정 게이트가 그대로 있다.게이트의 중심은
src/codex/catalog/native-models.ts의ACCOUNT_GATED_NATIVE_OPENAI_MODELS다. Sol/Terra/Luna(그리고 Daybreak Blue)가 여기 들어 있다. 카탈로그 동기화(src/codex/catalog/sync.ts)와 convergence(src/codex/convergence.ts)는 확인된 계정 로스터에 그 슬러그가 있을 때만 bare/account-bound 행을 남긴다.availableAccountGatedNativeModels/cachedAvailableAccountGatedNativeModels(src/codex/model-entitlements.ts)는confirmed이고 캐시가 살아 있으며 모델 집합에 슬러그가 있을 때만 true다. 확인이 없거나 스냅샷이 비면 fail-closed로 숨긴다. #2548이 “없는 계정에 보이던” 반대 문제를 막으려던 방향이고, #2550이 그 게이트를 세 슬러그에 붙인 뒤 2.33→2.35 경계와 맞물린다.그래서 건강한 Plus 계정에서도, 로스터/캐시가 비어 있거나 확인 플래그가 안 서면 Sol/Terra/Luna가 통째로 빠진다. 피커에 없으면
src/server/management/model-routes.ts의 visibility 대상 집합(supportedNative)에도 안 들어간다. enable이invalid model visibility target을 내는 이유가 그것이다. 숨김 토글 문제가 아니라, 카탈로그가 이미 그 아이디를 “지원 목록”에서 뺀 상태다. Terra/Luna가 마이그레이션 타깃으로만 남는다는 관찰도, 독립 선택 행이 게이트에 걸린 것과 맞다.이 이슈는 #2548의 반대말이고, #2718(needsReauth/키링)과도 겹치지 않는다. 여기는 인증이 건강하다. types/config 분할과 무관하다. 닫을 중복이 아니다. 지금
dev가 Kiro 쿼터 디스크 쪽을 다듬는 동안에도, 이 네이티브 게이트 false-negative는 그대로 사용자에게 보인다.src/codex/catalog/native-models.ts ACCOUNT_GATED_NATIVE_OPENAI_MODELS - Sol/Terra/Luna가 계정 확인 없이는 카탈로그에 안 남는다. #2550 이후 기본이 fail-closed다.
src/codex/catalog/sync.ts 약 1579-1620줄 / src/codex/convergence.ts 약 254-283줄 - bare·account-bound 둘 다 confirmed roster ∩ entitled slug일 때만 남긴다. 스냅샷이 비면 세 행이 같이 사라진다.
src/codex/model-entitlements.ts availableAccountGatedNativeModels / cachedAvailableAccountGatedNativeModels - confirmed·미만료·모델 집합 멤버십이 필요하다. “네이티브는 되는데 ocx 캐시만 비어 있음”이 여기로 떨어진다.
src/server/management/model-routes.ts 약 465-478줄 - enable 대상은 현재 native 행 집합에 있어야 한다. 게이트에 가려진 슬러그는 무조건
invalid model visibility target이다. 피커 캐시만의 문제가 아니다.경로/#2548 #2550 #2718 - #2548은 과다 노출, 이 이슈는 과소 노출이다. #2718은 reauth/키링이다. 합치지 말고, 로스터 확인이 실패해도 실제 권한이 있는 계정을 어떻게 복구할지 이 티켓에서 정하라.
메인테이너의 판단이 필요한 지점
- confirmed roster가 비었을 때 Plus/ ent이 확인된 계정에 Sol/Terra/Luna를 임시로 다시 펼칠지, 아니면 roster fetch를 고쳐서 confirmed를 반드시 채울지
- 캐시 miss를 “무권한”과 같은 취급으로 둘지, “아직 모름”으로 나눠 이전 live 행을 유지할지
- Daybreak Blue도 같은 게이트라서 이번 수정에 묶을지
- 2.35.x 핫픽스 후보로 볼지, 2.36 라인에서만 고칠지
너의 추천
이 이슈는 열어 두고, 엔타이틀먼트 스냅샷/확인 경로를 먼저 추적하는 버그 PR을 받는다. #2550 게이트 자체를 지우지 마라. 목표는 “확인된 무권한은 계속 숨기고, 건강한 실제 권한 계정에서 스냅샷이 비거나 stale일 때 false-negative가 나지 않게”다. 재현은 제보 A/B(네이티브·2.33·2.35)와ocx models live로 잠그라. enable 에러는 카탈로그가 돌아온 뒤 자동으로 사라져야 한다. types/config 분할 때문에 닫을 대상이 아니다.이 댓글은 grok-bot이 작성했습니다
- added a commit that references this issue
on Aug 29, 2026 Fixed on
devin c3da277 (#2891).Root cause. OpenCodex asked ChatGPT for your account's Codex model roster at
/backend-api/codex/models?client_version=0.0.0— a hardcoded placeholder. Upstream filters that
roster by the client version it is told, and this repository's own measurement records0.60.0
returning zero models where0.142.2returns five. So the request asked "what may a client from
before GPT-5.6 existed use?", got back a roster without it, and the fail-closed entitlement gate
read that as your account positively not having GPT-5.6. Nothing was wrong with your
subscription; the proxy was under-reporting itself.What changed. The version is now taken from your actual request (Codex was already sending it
and the value was being thrown away), falling back to the selected Codex runtime version, and
finally to the lowest version under which the gated models can be returned at all. A cached roster
is remembered per client version, so one client's answer is never reused for another.On the second half of your report —
POST /api/models/visibilityreturning
invalid model visibility targetforgpt-5.6-codex: that is fixed too, and it was a consequence
of the first bug. A model suppressed by the entitlement gate was absent from the list the endpoint
validated against, so you could not clear thedisabledModelsentry the bug had led you to set.
Worth being precise about the scope: that fix only lets the config write through. It does not by
itself make a model visible — entitlement still filters the catalog and routing stays gated — so it
is the client-version fix above that should restore the model for you.One thing I could not verify. Your report did not include a captured
/codex/modelsresponse,
so I cannot prove your machine took the confirmed-negative branch rather than hitting a transient
discovery failure; both produce the same symptom. The version-filter explanation is what the
source, the version boundary, and the measurement support, and the fix is correct either way. If
GPT-5.6 is still missing after you update, please reopen with a redacted capture of that response
and I will look again.Closing manually: pull requests here target
dev, so GitHub does not auto-close linked issues.Reproduced on OpenCodex 2.36.0 after a clean reinstall. Please reopen if appropriate.
I removed the existing OpenCodex installation, renamed the entire
~/.opencodexdirectory out of the way, reinstalled@bitkyc08/opencodex@2.36.0, ran a freshocx initwith only the native OpenAI/ChatGPT-login provider, installed the service, and ranocx sync --restart-codex.Result under OpenCodex 2.36.0:
$ ocx access models gpt-5.5 openai gpt-5.4 openai gpt-5.4-mini openai gpt-5.3-codex-spark openaigpt-5.6-sol,gpt-5.6-terra, andgpt-5.6-lunaare still absent from both/v1/modelsand the Codex App picker.A/B check with the same machine and same ChatGPT account:
ocx stop/ native Codex routing -> the Codex App immediately shows 5.6 Sol, 5.6 Terra, 5.6 Luna (plus 5.5/5.4/5.4 Mini).- Re-enable OpenCodex 2.36.0 -> all three GPT-5.6 rows disappear again.
Per the request in the closing comment, here is a redacted direct capture of the authenticated Codex model roster using the fallback client version introduced by #2891:
{ "endpoint": "/backend-api/codex/models", "client_version": "0.142.2", "http_status": 200, "model_count": 4, "models": [ { "slug": "gpt-5.5", "supported_in_api": true, "visibility": "list" }, { "slug": "gpt-5.4", "supported_in_api": true, "visibility": "list" }, { "slug": "gpt-5.4-mini", "supported_in_api": true, "visibility": "list" }, { "slug": "codex-auto-review", "supported_in_api": true, "visibility": "hide" } ] }No token, email, account id, request id, or other credential is included above.
This suggests the remaining issue may be that the current upstream roster no longer returns GPT-5.6 at the
0.142.2fallback floor, even though the same account is currently entitled to GPT-5.6 when native Codex uses its own client identity/version. In other words, the hardcoded0.0.0bug is fixed, but the fallback floor itself appears capable of producing the same confirmed-negative outcome now.Happy to provide another redacted roster capture using the actual native Codex client version if you want a direct version-to-version comparison.
Additional live upstream evidence from the same affected Windows machine/account:
I queried the authenticated Codex roster directly with three
client_versionvalues. The response was redacted to model slugs / visibility only.client_version=0.142.2 HTTP 200 gpt-5.5 gpt-5.4 gpt-5.4-mini codex-auto-review (hide) client_version=0.144.0 HTTP 200 gpt-5.6-sol gpt-5.6-terra gpt-5.6-luna gpt-reserve (hide) gpt-5.5 gpt-5.4 gpt-5.4-mini codex-auto-review (hide) client_version=0.146.0 HTTP 200 gpt-5.6-sol gpt-5.6-terra gpt-5.6-luna gpt-reserve (hide) gpt-5.5 gpt-5.4 gpt-5.4-mini codex-auto-review (hide)This machine also has no
codexCLI on PATH and no~/.opencodex/codex-runtime.jsonpersisted runtime record (onlyruntime-port.json). So background / management paths with no inboundclient_versionhave no usable tier-1 or tier-2 version evidence and fall through to the tier-3 floor.That makes the residual failure deterministic here:
0.142.2-> HTTP 200 confirmed roster -> GPT-5.6 omitted -> fail-closed entitlement projection suppresses Sol/Terra/Luna.The same account returns all three GPT-5.6 rows as soon as the roster is queried with
0.144.0or0.146.0, and native Codex App also exposes them.So the remaining issue after #2891 appears to be specifically that the tier-3 fallback is still too old for the current upstream roster filter. The repo's existing 2026-08-17 measurement also reports
0.144.0as the threshold where the GPT-5.6 rows appear, which matches this live test exactly.I have not pushed or installed any patch; this comment is just the additional reproduction / root-cause evidence requested in the issue thread.
Client or integration
Codex App
Area
Authentication and account pool
Summary
After upgrading from OpenCodex 2.20.0 to 2.35.0, the native OpenAI models below disappear from both
ocx models liveand the Codex App model picker:gpt-5.6-solgpt-5.6-terragpt-5.6-lunaThe authenticated ChatGPT account is a healthy Plus account:
This account is actually entitled to GPT-5.6:
gpt-5.6-solconversation completes successfully;Expected: a healthy account that can actually use these models should retain all three independent native catalog rows under OpenCodex routing.
Reproduction
gpt-5.6-solrequest completes.Each returns:
ocx models live, and a fresh Sol request succeeds.Controlled result:
Version
2.35.0
Operating system
Windows 11 Home 24H2, build 26100, x64
Codex runtime: 0.146.0
Provider and model
Canonical OpenAI provider using ChatGPT login:
gpt-5.6-solgpt-5.6-terragpt-5.6-lunaLogs or error output
In the generated catalog, Terra and Luna can still occur as migration targets, but not as independent selectable slugs. This is therefore not only a stale Codex App picker cache.
Screenshots and supporting files
The version/routing A/B matrix is included above. Additional redacted catalog excerpts can be supplied if needed.
Redacted configuration
{ "providers": { "openai": { "adapter": "openai-responses", "baseUrl": "https://chatgpt.com/backend-api/codex", "authMode": "forward" } } }Suspected regression boundary
This appears to be a false-negative entitlement/catalog projection rather than an actual account entitlement failure.
PR #2550 added
gpt-5.6-sol,gpt-5.6-terra, andgpt-5.6-lunatoACCOUNT_GATED_NATIVE_OPENAI_MODELS, making them fail closed when no confirmed per-account roster is available:#2550
That change is not present in v2.33.0 but is present in v2.35.0. This matches the observed version boundary, but I am not claiming that #2550 is the final root cause until the roster/cache path is traced.
Related reports are not exact duplicates:
needsReAuth/keyring credential handling and missing Daybreak models. In this report,needsReauth=false, authentication is healthy, and native Sol inference succeeds.Expected behavior
When the authenticated account's actual Codex entitlement supports these models, OpenCodex should:
Checks