Repository navigation
Connected catalog reports success while local Codex CLI rejects unsupported reasoning levels #4207
Description
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
- Use Windows with Codex CLI 0.135.0 and OpenCodex client 2.50.0.
- Connect to a hub whose exported model catalog includes
max/ultrareasoning levels. The observed hub is dev 2.51.0. - Confirm
ocx connect status --jsonreportsconnected, catalog present, token owned, and clean rotation. - Ensure
OPENCODEX_API_AUTH_TOKENis present in the child process; the audit explicitly loaded the owned client credential without printing it. - 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:145validates container/model/slug shape; it does not validate entries against the consuming local Codex version.src/client/hub-client.ts:468returns the downloaded body after that validation.src/client/connect.ts:542downloads and materializes the client catalog.src/codex/catalog/effort.ts:441is an existing local-runtime clamping entry point worth checking for reuse.src/cli/connect.ts:187prints 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.
Activity
Ingwannu commentedon Sep 10, 2026
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 commentedon Sep 10, 2026
리뷰 · 우선순위 71 / 80
이 이슈는 연결된 클라이언트가 허브 카탈로그를 받아
connected/ catalog present 로 성공을 찍는데, 로컬 Codex CLI(재현 환경 0.135.0)가 그 카탈로그 안의 reasoning levelmax/ultra를 파싱하지 못해 exec 전에 바로 죽는 문제를 말합니다. 허브·자격증명은 되고, 로컬 런타임만 못 먹는 “연결 성공 vs 실행 가능”이 한 상태로 섞여 있습니다.현재
devHEAD6101140ff(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/라우팅은 정상
메인테이너의 판단이 필요한 지점
너의 추천
클라이언트 쪽 compatible projection 또는 readiness block 을 추가하세요. 허브 카탈로그를 조용히 편집하지 말고, 로컬 Codex CLI 지원 effort 에 맞춰 표시/실행 카탈로그를 투영하거나, 호환 불가면 connect status 에 명확한 차단/경고를 넣으세요. #4204 는 설계로 열어 두고, 이 PR 범위는 client projection/readiness 로 한정하세요.
이 댓글은 grok-bot이 작성했습니다
lidge-jun commentedon Sep 11, 2026
Landed via #4240 at
babb76449fdondev. Client path now refuses an unparseable hub catalog before write (catalogEffortCompatibilitygate on connect/sync).lidge-jun commentedon Sep 11, 2026
Closed: fix is on
devvia #4240 (babb76449fd).fix(client): refuse a hub catalog the local Codex CLI cannot parse
client: report local Codex readiness instead of bare connected state
client: report local Codex readiness instead of bare connected state
fix(client): refuse a hub catalog the local Codex CLI cannot parse
client: report local Codex readiness instead of bare connected state