[Bug] Codex 0.153.4 rejects 'minimal'/'none' on gpt-6-astra mapped custom models

[leonclab]

Proven native-alias normalization landed; reported gateway case remains open

#3804 (0a4e4bc9bf) normalizes custom reasoning lists only for capability-backed canonical Codex-forward aliases. Arbitrary YYLJ gateway capability and the reported Desktop-version case remain unverified.

Verified against dev 5759d9ea2f1e7281cdc01eb9628f2e0a123fb59c. Original report by @leonclab. The attribution record was added in #3811.

Client or integration

Codex App

Area

Catalog / models

Summary

In the latest Codex Desktop runtime (0.153.4, Darwin arm64), the native binary strictly validates supported reasoning efforts for gpt-6-astra and only permits ['low', 'medium', 'high', 'xhigh', 'max']. Supplying minimal or none causes Codex to immediately reject the request before dispatch with:
Unsupported value: 'minimal' is not supported with the 'gpt-6-astra' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.

While OpenCodex logs [opencodex] Removed unsupported reasoning efforts: minimal, none, custom models mapped to Astra (e.g., forward proxy YYLJ/gpt-6-astra with legacy customModels[*].reasoningEfforts containing minimal or none) still have those unsupported efforts preserved in opencodex-catalog.json and turn execution contexts, triggering client-side rejection.

Reproduction

1. Configure a custom model in ~/.opencodex/config.json pointing to an Astra upstream:

{
  "provider": "YYLJ",
  "modelId": "gpt-6-astra",
  "reasoningEfforts": ["none", "minimal", "low", "medium", "high", "xhigh", "max"]
}

2. Run ocx sync.
3. In Codex Desktop (version 0.153.4), start a turn or assign a subtask with reasoning effort minimal.
4. Observe the immediate 400 error:

{"type":"error","error":{"type":"invalid_request_error","code":"unsupported_value","message":"Unsupported value: 'minimal' is not supported with the 'gpt-6-astra' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.","param":"reasoning.effort"},"status":400}

Version

@bitkyc08/opencodex 2.43.0

Operating system

macOS 15.5 (Darwin arm64)

Provider and model

custom / gpt-6-astra

Logs or error output

[opencodex] Removed unsupported reasoning efforts: minimal, none
Unsupported value: 'minimal' is not supported with the 'gpt-6-astra' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.

Redacted configuration

{
  "customModels": [
    {
      "provider": "YYLJ",
      "modelId": "gpt-6-astra",
      "reasoningEfforts": ["none", "minimal", "low", "medium", "high", "xhigh", "max"]
    }
  ]
}

Checks

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

[lidge-jun]

리뷰 · 우선순위 71 / 80

이 이슈는 Codex Desktop 0.153.4가 네이티브 gpt-6-astra에 대해 reasoning effort를 low / medium / high / xhigh / max만 허용하는데, OpenCodex 쪽 custom model이 Astra로 매핑되면서 minimal·none이 카탈로그와 턴 실행 맥락에 남는 버그입니다. 재현은 명확합니다. customModels에 modelId: "gpt-6-astra"와 레거시 사다리 ["none","minimal","low",...]를 넣고 ocx sync한 뒤 Desktop에서 minimal로 턴을 시작하면, 디스패치 전에 바로 unsupported_value 400이 납니다. 로그에는 [opencodex] Removed unsupported reasoning efforts: minimal, none이 찍히는데도, 리포터 말대로 커스텀 매핑 쪽에는 그 값이 남아 Desktop이 거절합니다. “클램프가 돌았다”는 신호와 “피커/턴에는 아직 있다”는 결과가 같이 보이는 상태입니다.

지금 dev HEAD는 bd1cda99c(package 2.44.0, #3768 credential 선택 공유까지 들어간 release-244)입니다. 관련 코드는 이미 레포에 있습니다. src/codex/catalog/provider-fetch.ts는 커스텀 행이 reasoningEfforts 배열을 선언하면 그대로 복사합니다(대략 L2413). 네이티브 별칭이면 codexForwardNativeCapabilityAlias도 붙입니다. src/codex/catalog/sync.ts의 deriveEntry는 그 별칭이 있으면 applyReasoningLevels(..., preserveExact=true)로 사다리를 정확히 보존합니다(대략 L364–L368). 나중에 clampCatalogModelsToCodexSupport(sync.ts L1857, 구현은 src/codex/catalog/effort.ts)가 “Codex 번들 카탈로그 전체에서 관측한 effort 합집합”으로 전역 클램프를 하고, 제거분은 formatClampLogLines(src/codex/runtime.ts L665–L668)로 로그합니다. 문제는 이 전역 합집합이 모델별 Astra 허용 목록이 아니라는 점입니다. 어떤 다른 네이티브가 아직 minimal/none을 갖고 있으면 Astra 매핑 커스텀 행에서도 안 깎일 수 있고, 반대로 전역에서 깎여 로그가 나와도 요청 경로·설정 원본·다른 쓰기 경로에 값이 남아 Desktop이 거절할 수 있습니다.

더 직접적인 구멍도 있습니다. nativeEffortClamp / shouldApplyNativeEffortClamp(effort.ts L52–L86)는 요청 model id에 /가 있으면 아예 스킵합니다. 그래서 YYLJ/gpt-6-astra 같은 routed slug는 요청 시점 네이티브 클램프를 못 받습니다. 핀된 업스트림 src/codex/data/upstream-models.json의 Astra 사다리는 low..max,ultra(default low)인데, 리포터가 본 0.153.4 에러 문구는 ultra도 없고 minimal/none도 없습니다. 즉 “핀 데이터 / 라이브 Desktop / 커스텀 명시 사다리” 세 층이 어긋쳐 있습니다. types/config 분할로 무효화될 이슈가 아니고, 카탈로그·effort 정합성 버그로 수락 가치가 큽니다. 리포터 버전은 2.43.0이지만 HEAD 2.44.0에서도 위 경로 구조는 그대로라 재확인이 필요합니다.

경로 src/codex/catalog/provider-fetch.ts 커스텀 reasoningEfforts 복사 - 명시 사다리를 네이티브 Astra 허용 목록과 교집합하지 않고 그대로 넣음
경로 src/codex/catalog/sync.ts deriveEntry preserveExact - codexForwardNativeCapabilityAlias일 때 커스텀 사다리를 정확히 보존해 minimal/none이 카탈로그 행에 남을 수 있음
경로 src/codex/catalog/effort.ts clampCatalogModelsToCodexSupport - 전역 Codex 어휘 합집합만 보고 모델별 Astra 허용 목록과 교차하지 않음
경로 src/codex/catalog/effort.ts nativeEffortClamp / shouldApplyNativeEffortClamp - routed provider/model slug는 요청 시점 클램프에서 제외됨
경로 src/codex/data/upstream-models.json gpt-6-astra - 핀 사다리에 ultra가 있는데 0.153.4 에러 문구의 허용 목록과 불일치 가능
경로 src/codex/runtime.ts formatClampLogLines - 전역 제거 로그만으로 “커스텀 매핑 행까지 깨끗하다”고 보장하지 못함

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

• 고정을 “카탈로그 sync 시 커스텀·별칭 행을 nativeReasoningEfforts(modelId) 또는 라이브 관측 사다리와 교집합”할지, “요청 시점 routed slug에도 native-alias clamp를 적용”할지, 둘 다 할지
• customModels.reasoningEfforts에 사용자가 넣은 minimal/none을 조용히 깎을지, sync/doctor 경고 후 깎을지(설정 원본을 바꿀지 카탈로그 투영만 바꿀지)
• 핀된 upstream-models.json Astra 사다리(ultra 포함)를 0.153.4 실측 목록에 맞춰 내릴지, ultra는 별건으로 둘지
• 재현 픽스처를 ocx sync 후 opencodex-catalog.json의 YYLJ/gpt-6-astra(또는 동등 slug) supported_reasoning_levels에 minimal/none이 없음을 단언하는 통합 테스트로 넣을지

너의 추천
수락하세요. codexForwardNativeCapabilityAlias가 켜진 커스텀/포워드 행은 sync 때 reasoningEfforts를 네이티브 Astra(또는 해당 alias) 허용 사다리와 반드시 교집합하고, routed slug에도 같은 교집합이 요청 경로에 적용되게 하세요. 전역 clampCatalogModelsToCodexSupport만으로 “모델별 Desktop 거절”을 막았다고 보지 마세요. 회귀 테스트는 sync 결과 카탈로그 행에 minimal/none이 없고, Desktop이 받는 effort 목록이 low..max(필요 시 실측 ultra 정책)만 남는지 고정하면 됩니다. release-244 방향과도 맞고, 작은 범위로 빨리 들어갈 수 있습니다.

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

[lidge-jun]

Track 2 delivered a scoped part in #3804: explicit reasoning lists for existing, capability-backed canonical Codex-forward aliases are intersected with the proven native ladder; defaults stay in the resulting list, explicit empty lists remain empty, and repeat sync does not re-add max.

Keeping this issue open: arbitrary gateway capability and the reported Desktop-version-specific behavior have not been verified. The change must not be read as proof that the reported gateway/Desktop case is fixed.

[lidge-jun]

Fixed on dev via #4499, merged inside lane I3's tip #4500 (merge commit 94063d0, verified as an ancestor of origin/dev).

Your report turned out to be the missing evidence rather than a duplicate. #3804 had already bounded canonical openai Codex-forward custom Astra rows, but it deliberately left unproven gateways unbounded and said Desktop gateway evidence was still required. Desktop naming 'gpt-6-astra' in the 400 — not the provider prefix — is that evidence, which is why YYLJ/gpt-6-astra was still failing.

The fix intersects an explicit custom reasoningEfforts list with pinned native metadata whenever the model id carries native capability metadata, gateways included. Two things deliberately did not change: full native identity (Responses Lite, multi-agent, context windows, display names) still requires the canonical openai forward destination, and stored configuration is untouched.

For the record, since they look related and are not: #4349 (effort ceilings enforced independently of pins) and #4409 (routed effort ladders from models.dev) do not fix this catalog projection, and request-time nativeEffortClamp still skips routed slugs.

Verified with client_version=0.153.4 discovery bounding both openai/gpt-6-astra and YYLJ/gpt-6-astra to ["low"]. Closing manually because this merges into dev rather than the default branch.