Connected catalog reports success while local Codex CLI rejects unsupported reasoning levels

[lidge-jun]

Client or integration

Codex CLI

Area

Catalog / models

Summary

A remote client reports connected, has a present/synced catalog, and can authenticate to the hub, but its installed Codex CLI exits before making a request because the downloaded catalog contains the unsupported reasoning level max.

The connection completion state does not distinguish “hub and credential work” from “the selected local Codex runtime can consume this catalog.” This is especially confusing because ocx status recognizes the older runtime and reports an active effort clamp while the materialized client catalog still fails to parse.

Reproduction

1. Use Windows with Codex CLI 0.135.0 and OpenCodex client 2.50.0.
2. Connect to a hub whose exported model catalog includes max/ultra reasoning levels. The observed hub is dev 2.51.0.
3. Confirm ocx connect status --json reports connected, catalog present, token owned, and clean rotation.
4. Ensure OPENCODEX_API_AUTH_TOKEN is present in the child process; the audit explicitly loaded the owned client credential without printing it.
5. Launch codex exec --ephemeral --skip-git-repo-check --color never "Reply with OK." in a scratch directory.

Observed: exit 1 before inference with the catalog parse error below. Independently authenticated catalog retrieval and routed responses through the hub work. This is not a missing-token or upstream-model failure.

Version

OpenCodex client 2.50.0; hub 2.51.0 / 6d3ad12e3fbfd8423f1515a467db4d3349732886; selected Codex CLI 0.135.0.

Operating system

Windows 11 25H2 client; macOS 27.0 hub.

Provider and model

Catalog compatibility, before any provider request.

Logs or error output

failed to parse model_catalog_json path <CODEX_HOME>/opencodex-catalog.json as JSON:
unknown variant `max`, expected one of `none`, `minimal`, `low`, `medium`, `high`, `xhigh`

Fresh probe: exitCode=1, tokenPresent=true, catalogCompatibilityError=true

Screenshots and supporting files

• src/client/hub-client.ts:145 validates container/model/slug shape; it does not validate entries against the consuming local Codex version.
• src/client/hub-client.ts:468 returns the downloaded body after that validation.
• src/client/connect.ts:542 downloads and materializes the client catalog.
• src/codex/catalog/effort.ts:441 is an existing local-runtime clamping entry point worth checking for reuse.
• src/cli/connect.ts:187 prints the successful connection without a local-launch compatibility result.

Expected completion: validate the selected local runtime before claiming it is ready, and either create a compatible local projection while preserving hub truth, or explicitly block local readiness with an upgrade/reselect action. Preserve the prior known-good catalog if compatibility cannot be established. Do not silently edit the hub catalog or automatically terminate running Codex processes.

Related: #3729 discusses remote catalog delivery/validation. This is a concrete failure in the implemented connected-client flow, not a second request for a remote catalog command.

Redacted configuration

model_provider = "opencodex"
model_catalog_json = "<CODEX_HOME>/opencodex-catalog.json"
[model_providers.opencodex]
base_url = "https://hub.example.ts.net:8443/v1"
env_key = "OPENCODEX_API_AUTH_TOKEN"

Checks

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

[Ingwannu]

Confirmed the gap on dev 6d3ad12: validateRemoteCatalog checks the container, row and slug structure, while downloadClientCatalog returns the same body and connect.ts writes that body to DEFAULT_CATALOG_PATH before injection. Those checks do not establish that the selected local Codex can parse its reasoning enum.

Please keep this linked to #4204 but not merged as a duplicate. They fail in opposite directions: #4204 can over-clamp Desktop using an older standalone runtime, while this path can deliver a newer hub catalog unprojected to an older client. A single global “allow max/ultra” or “strip max/ultra” switch would fix one while regressing the other.

The projection/readiness decision must be bound to the actual consuming runtime and preserve the canonical hub catalog separately. Cover a legacy CLI, newer Desktop beside it, missing/untrusted runtime evidence, failed download/projection, and preservation of the prior owned catalog. Do not treat connected/authenticated as parse-ready or restart active consumers to make readiness appear complete.

[lidge-jun]

리뷰 · 우선순위 71 / 80

이 이슈는 연결된 클라이언트가 허브 카탈로그를 받아 connected / catalog present 로 성공을 찍는데, 로컬 Codex CLI(재현 환경 0.135.0)가 그 카탈로그 안의 reasoning level max/ultra 를 파싱하지 못해 exec 전에 바로 죽는 문제를 말합니다. 허브·자격증명은 되고, 로컬 런타임만 못 먹는 “연결 성공 vs 실행 가능”이 한 상태로 섞여 있습니다.

현재 dev HEAD 6101140ff(package.json 2.51.0) 기준으로 보면, src/client/hub-client.ts 의 validateRemoteCatalog 는 models 배열·slug 형태만 검사하고, 로컬 CLI가 지원하는 effort enum까지는 보지 않습니다. src/codex/catalog/effort.ts 에는 nativeEffortClamp 와 catalog clamp 진입점이 있고, src/cli/connect.ts 의 status/성공 출력은 connection·catalog present 중심이라 “이 머신의 Codex가 이 카탈로그를 먹을 수 있는가” readiness 가 없습니다. 그래서 사용자는 ocx connect status 가 깨끗한데 codex exec 만 실패하는 상황을 만납니다.

#4204(Windows 오래된 CLI가 Desktop보다 낮아 max/ultra 를 깎는 설계)와 같은 축이지만, 이 이슈의 핵심은 Desktop consumer identity 가 아니라 클라이언트에 투영된 카탈로그와 로컬 CLI 호환성입니다. 허브 카탈로그를 조용히 고치면 다른 클라이언트·Desktop 에 부작용이 납니다. Feasibility 에서도 L4 설계(#4204)와 구분하고, 클라이언트 쪽 compatible projection / readiness block 을 권한 준 이유가 여기입니다.

라인 - src/client/hub-client.ts validateRemoteCatalog — 스키마(slug)만 검증하고 로컬 CLI effort 지원 범위는 검사하지 않음
라인 - src/cli/connect.ts connect status / Connected 성공 경로 — catalog present·토큰만으로 success; 로컬 런타임 호환 readiness 없음
경로/심볼 - src/codex/catalog/effort.ts nativeEffortClamp / clamp 진입 — 서버·동기화 쪽 clamp 는 있으나 connected-client 투영에 연결되지 않음
경로/심볼 - 재현 증상 — hub catalog 에 max/ultra 포함 + 로컬 CLI 0.135 가 catalog parse 로 exit 1; 허브 직접 auth/라우팅은 정상

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

• 클라이언트에만 호환 projection(로컬 CLI가 모르는 rung 제거/다운그레이드)을 둘지, 아니면 readiness 실패로 connect/status 를 막거나 경고만 할지
• 허브 원본 카탈로그를 클라이언트 자격으로 수정하는 경로는 절대 금지할지(권장: 금지)
• [Bug][Windows] Stale persisted CLI 0.135.0 strips max/ultra while Codex Desktop runs 0.153.4 #4204 설계 이슈와 한 lane 으로 묶을지, 이번 round 는 클라이언트 projection 만 먼저 할지

너의 추천
클라이언트 쪽 compatible projection 또는 readiness block 을 추가하세요. 허브 카탈로그를 조용히 편집하지 말고, 로컬 Codex CLI 지원 effort 에 맞춰 표시/실행 카탈로그를 투영하거나, 호환 불가면 connect status 에 명확한 차단/경고를 넣으세요. #4204 는 설계로 열어 두고, 이 PR 범위는 client projection/readiness 로 한정하세요.

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

[lidge-jun]

Landed via #4240 at babb76449fd on dev. Client path now refuses an unparseable hub catalog before write (catalogEffortCompatibility gate on connect/sync).

[lidge-jun]

Closed: fix is on dev via #4240 (babb76449fd).