[Bug][2.35][Codex App] Entitled GPT-5.6 Sol/Terra/Luna disappear from the native catalog

[stud-f]

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 live and the Codex App model picker:

• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.6-luna

The authenticated ChatGPT account is a healthy Plus account:

plan=plus
active=true
needsReauth=false
WHAM reachability: status=200, authenticated

This account is actually entitled to GPT-5.6:

• stopping OpenCodex and restoring native Codex routing makes GPT-5.6 immediately reappear;
• a fresh native gpt-5.6-sol conversation completes successfully;
• OpenCodex 2.33.0 also advertises Sol/Terra/Luna for the same account, and Sol completes successfully.

Expected: a healthy account that can actually use these models should retain all three independent native catalog rows under OpenCodex routing.

Reproduction

1. Sign in to Codex with a ChatGPT Plus account that can use GPT-5.6.
2. Verify under native Codex routing that GPT-5.6 appears and a fresh gpt-5.6-sol request completes.
3. Install and start OpenCodex 2.35.0 with the same account.
4. Fully restart Codex App.
5. Run:

ocx models live

6. Observe that the native OpenAI portion contains only:

gpt-5.5
gpt-5.4
gpt-5.4-mini
gpt-5.3-codex-spark

7. Sol/Terra/Luna are absent from the live catalog and the Codex picker.
8. Attempts to enable them manually fail:

ocx models enable gpt-5.6-sol
ocx models enable gpt-5.6-terra
ocx models enable gpt-5.6-luna

Each returns:

Error: invalid model visibility target

9. Stop OpenCodex, restore native routing, and fully restart Codex App. GPT-5.6 reappears and a fresh Sol request succeeds.
10. Run OpenCodex 2.33.0 with the same account. Sol/Terra/Luna return to ocx models live, and a fresh Sol request succeeds.

Controlled result:

Routing/version	Catalog	Real request
OpenCodex 2.35.0	Sol/Terra/Luna absent	Cannot select them normally
Native Codex, same account	GPT-5.6 present	Fresh Sol request succeeds
OpenCodex 2.33.0, same account	Sol/Terra/Luna present	Fresh Sol request succeeds

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-sol
• gpt-5.6-terra
• gpt-5.6-luna

Logs or error output

$ ocx models live

gpt-5.5
gpt-5.4
gpt-5.4-mini
gpt-5.3-codex-spark

$ ocx models enable gpt-5.6-sol
Error: invalid model visibility target

$ ocx models enable gpt-5.6-terra
Error: invalid model visibility target

$ ocx models enable gpt-5.6-luna
Error: invalid model visibility target

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, and gpt-5.6-luna to ACCOUNT_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:

• [Bug]: account-unentitled gpt-5.6-sol/terra/luna are advertised as native models and relayed as 502 stream errors #2548 reports the inverse problem: unentitled accounts were incorrectly shown these models.
• Constantly reporting "Needs re-authentication" and does not provide the full model catalog #2718 involves persistent 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:

1. retain Sol/Terra/Luna as independent live catalog rows;
2. expose them in the Codex App picker;
3. allow them to be selected and routed;
4. avoid treating a missing or stale entitlement snapshot as proof that a healthy, actually entitled account is unentitled.

Checks

• I searched existing open and closed issues, pull requests, and documentation.
• I removed emails, account IDs, OAuth tokens, API keys, request IDs, and personal filesystem paths.

[lidge-jun]

리뷰 · 우선순위 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가 “없다”고 잘못 접는 쪽에 가깝다. 지금 dev HEAD(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이 작성했습니다

[lidge-jun]

Fixed on dev in 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 records 0.60.0
returning zero models where 0.142.2 returns 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/visibility returning
invalid model visibility target for gpt-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 the disabledModels entry 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/models response,
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.

[juzijia]

Reproduced on OpenCodex 2.36.0 after a clean reinstall. Please reopen if appropriate.

I removed the existing OpenCodex installation, renamed the entire ~/.opencodex directory out of the way, reinstalled @bitkyc08/opencodex@2.36.0, ran a fresh ocx init with only the native OpenAI/ChatGPT-login provider, installed the service, and ran ocx 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  openai

gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna are still absent from both /v1/models and 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.2 fallback 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 hardcoded 0.0.0 bug 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.

[juzijia]

Additional live upstream evidence from the same affected Windows machine/account:

I queried the authenticated Codex roster directly with three client_version values. 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 codex CLI on PATH and no ~/.opencodex/codex-runtime.json persisted runtime record (only runtime-port.json). So background / management paths with no inbound client_version have 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.0 or 0.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.0 as 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.