[Bug][Windows][Codex App] Generated catalog keeps the pre-0.151 schema: shell_type pinned to shell_command, four 0.151 fields never emitted

Client or integration

Codex App

Area

Catalog / models

Summary

After Codex Desktop self-updated its bundled runtime to codex-cli 0.151.0-alpha.7.1, the Codex app-server started crash-looping within minutes ("ChatGPT hit a snag"). The same OpenCodex 2.33.0 proxy process had been running for 22.8 hours with a completely stable app-server immediately before that update, so the proxy itself is not the new variable — the Codex version is.

The catalog OpenCodex writes to model_catalog_json appears to be built for the pre-0.151 model schema. Three concrete divergences, all verified by diffing OpenCodex's opencodex-catalog.json against the models_cache.json that Codex 0.151 fetched for itself:

1. shell_type disagrees on every native model. Codex 0.151 reports unified_exec; OpenCodex writes shell_command for 10/10 rows in the generated catalog.

model	Codex 0.151 `models_cache.json`	OpenCodex catalog
`gpt-5.6-sol`	`unified_exec`	`shell_command`
`gpt-5.6-terra`	`unified_exec`	`shell_command`
`gpt-5.6-luna`	`unified_exec`	`shell_command`
`gpt-5.5`	`unified_exec`	`shell_command`
`gpt-5.4`	`unified_exec`	`shell_command`
`gpt-5.4-mini`	`unified_exec`	`shell_command`
`gpt-5.3-codex-spark`	`unified_exec`	`shell_command`
`codex-auto-review`	`unified_exec`	`shell_command`

2. The value is pinned in two places, and one of them is a validator. grep -rn "unified_exec" src/ returns 0 hits in 2.33.0 — the newer value is not known to the codebase at all.

src/codex/catalog/sync.ts:378 hardcodes shell_type: "shell_command" in the entry it builds.
src/codex/catalog/metadata.ts:551 — hasNativeCatalogRowShape() requires entry.shell_type === "shell_command". A row whose genuine value is unified_exec therefore can never satisfy the native-row shape check, so it cannot survive as-is even when upstream data is correct.

3. Four fields that 0.151 emits are never written. Each returns 0 references in src/:

node_repl_disabled
node_repl_auto_review_required
include_plugin_usage_instructions
include_apps_usage_instructions

Since config.toml's model_catalog_json makes Codex consume the OpenCodex catalog instead of its own models_cache.json, the app-server ends up running with the wrong tool-surface definition and without the node_repl / plugin gating flags. This matters more on setups that actually use those features — this machine has node_repl configured as an MCP server and 14 plugins enabled.

Removing that one config line resolves it. ocx stop (which un-injects model_catalog_json and openai_base_url) restored stability immediately; the app has been stable since. Notably the catalog file itself is still on disk — Codex simply stops reading it — which points at the catalog contents rather than at the proxy being in the request path.

Possibly relevant: ocx status reports Codex runtime: ...\npm\codex.cmd, Codex version: 0.146.0, Codex source: configured, while the Desktop app now bundles 0.151.0-alpha.7.1. If the catalog is generated against the pinned CLI version rather than the runtime the app actually launches, that would explain why the generated rows kept the 0.146-era shape. Catalog clamp: inactive.

This looks like the same class of defect as #1408 (OpenCodex injecting a shape that a newer Codex rejects, crashing the Desktop app), one Codex version later.

Reproduction

Windows 11, OpenCodex 2.33.0, Codex Desktop with bundled codex-cli 0.151.0-alpha.7.1 (app 26.825.5331.0, client 26.825.41651).
ocx start — injects openai_base_url and model_catalog_json into ~/.codex/config.toml.
Open Codex Desktop and do normal work (several threads, spawn_agent sub-agents, node_repl MCP server configured, plugins enabled).
The app-server dies and respawns every few minutes; the app shows "ChatGPT hit a snag".
ocx stop → app-server stays up.

Diff that shows the divergence:

# what Codex 0.151 fetched for itself
jq '.models[] | select(.slug=="gpt-5.6-sol") | {slug, shell_type, node_repl_disabled}' ~/.codex/models_cache.json
# -> "unified_exec", false

# what OpenCodex wrote and pointed Codex at
jq '.models[] | select(.slug=="gpt-5.6-sol") | {slug, shell_type, node_repl_disabled}' ~/.codex/opencodex-catalog.json
# -> "shell_command", null (key absent)

Version

2.33.0

Operating system

Windows 11 Pro (build 26200)

Provider and model

openai / gpt-5.6-sol (native passthrough; also affects terra, luna, and the other native rows)

Logs or error output

# app-server lifetimes from Codex's own diagnostic log DB.
# The proxy (bun, PID 27032) started 08-28 05:03:49 and ran continuously across this whole window.

08-28 00:03:22 -> 08-28 03:04:05   alive  10843s
08-28 03:04:28 -> 08-28 03:37:25   alive   1977s
08-28 05:01:46 -> 08-29 03:51:43   alive  82197s   <-- 22.8 h, proxy running the entire time
--------------- 03:56  Codex Desktop self-updates to codex-cli 0.151.0-alpha.7.1 ---------------
08-29 03:52:38 -> 08-29 03:56:12   alive    214s
08-29 03:56:38 -> 08-29 03:57:23   alive     45s
08-29 03:57:38 -> 08-29 04:07:44   alive    606s
08-29 04:23:33 -> 08-29 04:28:41   alive    308s
08-29 04:29:21 -> 08-29 04:34:36   alive    315s
08-29 04:36:09 -> 08-29 04:41:07   alive    298s
08-29 04:41:57 -> 08-29 04:44:17   alive    140s
--------------- 04:41  proxy stopped (model_catalog_json un-injected) -> stable ---------------

# The app-servers stop mid-stream with no panic and no error record, so I could not
# capture an exit code or stack. The correlation above plus the schema diff is the
# evidence I have; I have NOT proven the exact crash instruction.

# Also present on every thread/start and thread/resume (understood to be by design,
# and gated on `websockets: false` — including only in case the churn is relevant):
ERROR codex_api::endpoint::responses_websocket ...
  transport="responses_websocket" websocket.warmup=true
  failed to connect to websocket: HTTP error: 426 Upgrade Required,
  url: ws://127.0.0.1:10100/v1/responses

Redacted configuration

{
  "websockets": false,
  "defaultProvider": "openai",
  "subagentModels": ["gpt-5.6-luna", "gpt-5.6-sol", "gpt-5.6-terra", "deepseek/deepseek-v4-flash"],
  "providers": {
    "openai": { "modelContextWindows": { "gpt-5.6-sol": 922000 } }
  }
}

Relevant ~/.codex/config.toml (injected lines plus the features that the missing catalog fields govern):

model_catalog_json = "C:\Users\[USER]\.codex\opencodex-catalog.json"
openai_base_url = "http://127.0.0.1:10100/v1"

[features]
multi_agent = true

[mcp_servers.node_repl]
command = 'C:\Users\[USER]\AppData\Local\OpenAI\Codex\runtimes\cua_node\...\node_repl.exe'

Suggested fix

Stop pinning shell_type to "shell_command" (sync.ts:378) and accept/propagate unified_exec.
Relax hasNativeCatalogRowShape() (metadata.ts:551) so both values validate, rather than treating shell_command as the definition of a native row.
Pass through node_repl_disabled, node_repl_auto_review_required, include_plugin_usage_instructions, and include_apps_usage_instructions from the upstream model data.
Consider generating the catalog against the runtime the Desktop app actually launches rather than the source=configured CLI version, or warn when the two diverge.

Correction from the reporter — please disregard the causal claim in the title and summary.

I have since reproduced the crash with OpenCodex fully stopped, so the proxy and its catalog are not the cause. Retracting that part before it costs anyone time.

What I observed after filing:

Proxy down (no bun process, /v1/models unreachable), and model_catalog_json / openai_base_url both absent from config.toml — verified, not assumed.
The Codex app-server still died 13 seconds into startup and was respawned.
Its entire 13-second life was startup work: rmcp::service / codex_rmcp_client::stdio_server_launcher / rmcp::transport::child_process launching MCP servers, plus thread_history and models_manager. It never reached a turn. All MCP servers then logged quit_reason=Cancelled, and one of them (node_repl) logged Child exited gracefully exit code: 1.

That shape matches openai/codex#21761 (Windows Desktop restarting while resuming threads and enumerating MCP tools) far better than anything in this repo. The earlier "22.8 h stable, then crash-loops" correlation misled me: the proxy restart and the Codex 0.151 self-update happened within minutes of each other, so I attributed to the proxy what the Codex update had introduced.

What still stands, independent of the crash. The schema divergence itself is reproducible and I believe still worth fixing — it just is not proven to cause any crash:

shell_type is unified_exec in Codex 0.151's own models_cache.json for all native models, and shell_command in the generated catalog.
grep -rn "unified_exec" src/ returns 0 hits in 2.33.0; the value is hardcoded at sync.ts:378 and required by hasNativeCatalogRowShape() at metadata.ts:551.
node_repl_disabled, node_repl_auto_review_required, include_plugin_usage_instructions, and include_apps_usage_instructions are emitted by 0.151 and never written by the catalog generator.

I have retitled the issue to describe only what I can actually support. Please close it if you would rather have a clean report; I would rather withdraw an overstated claim than leave it standing. Apologies for the noise.

리뷰 · 우선순위 71 / 80

설명

Codex Desktop이 번들 런타임을 codex-cli 0.151.0-alpha.7.1로 올린 직후 app-server가 크래시 루프("ChatGPT hit a snag")에 들어갔고, 그 직전까지 같은 OpenCodex 2.33.0 프록시는 22.8시간 동안 안정이었다는 보고입니다. 변수는 프록시가 아니라 Codex 쪽 스키마 기대치입니다.

작성자가 opencodex-catalog.json과 Codex 0.151 models_cache.json을 비교해 세 갈래를 짚었습니다. (1) 모든 네이티브 모델의 shell_type이 Codex는 unified_exec인데 OpenCodex는 shell_command로 고정, (2) 0.151에 생긴 필드 네 개가 OpenCodex 생성 카탈로그에 없음, (3) 결과적으로 app-server가 카탈로그를 거부하거나 비정상 종료. 현재 dev의 src/codex/catalog/sync.ts 폴백 엔트리(약 378행)는 여전히 shell_type: "shell_command"를 박고, src/codex/catalog/metadata.ts의 hasNativeCatalogRowShape(약 551행)도 entry.shell_type === "shell_command"를 요구합니다. 즉 HEAD도 0.151 기대를 아직 반영하지 않은 상태입니다.

이 이슈는 카탈로그/플랫폼 호환 버그로, 현재 dev 방향(엔타이틀먼트 client_version #2891, pool 401 #2889)과 축은 다르지만 Codex Desktop 사용자가 업데이트만 해도 전체가 죽는 급함이 있습니다. #2862 routed catalog eligibility sanitize, #2839 catalog verbosity 등과 같은 catalog 열차에 сосед합니다. types/config 분할로 무효화될 종류가 아닙니다.

고칠 때는 shell_type만 바꾸면 안 됩니다. hasNativeCatalogRowShape가 shell_command를 하드조건으로 두고 있어, 생성기를 unified_exec로 바꾸면 관측 네이티브 행 필터가 반대로 깨질 수 있습니다. 0.151 필드 네 개(이슈 본문 상세)도 함께 맞추고, 구버전 Codex와의 하위호환(언제 shell_command를 유지할지)을 버전 게이트로 묶어야 합니다.

경로 src/codex/catalog/sync.ts:378 - 폴백 RawEntry가 shell_type: "shell_command" 고정. 0.151 Desktop은 unified_exec를 기대합니다.
경로 src/codex/catalog/metadata.ts:551 - hasNativeCatalogRowShape가 shell_type === "shell_command"를 요구해, 생성기만 바꾸면 네이티브 shape 가드가 회귀합니다. 같이 고쳐야 합니다.
경로 model_catalog_json 주입(src/codex/inject.ts) - 카탈로그 파일 내용이 Desktop app-server 파서와 어긋나면 프록시 health는 green인데 UI만 죽습니다. doctor에 catalog schema 세대/codex-cli 버전 힌트가 있으면 디버깅이 쉽습니다.
경로 이슈 본문 필드 4개 - 이름·타입이 재현의 핵심이므로, 패치 PR은 Codex 0.151 models_cache 샘플 fixture와 strict 파서로 고정해야 합니다.

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

Codex CLI 버전별로 shell_type을 분기할지, 0.151+만 지원하고 최저 지원 버전을 올릴지
hasNativeCatalogRowShape를 unified_exec도 받아들이게 완화할지
Windows Desktop만의 문제인지 CLI 0.151 일반인지도 확인 범위
2.36.0 라인에 핫픽스로 넣을지 catalog 캠페인에 묶을지

너의 추천
우선순위 높게 유지하세요. shell_type + shape 가드 + 0.151 신규 필드를 한 단위로 고치는 버그 PR을 받는 게 맞습니다. 재현 fixture로 0.151 models_cache.json 일부를 tests에 넣고, Desktop 최소 버전 매트릭스를 PR에 명시하세요. 닫지 마세요.

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

fix(catalog): accept unified_exec rows and restore plugin usage instr…

Addressed on dev in 7d37c8a (#2907) — but not in the way the report framed it, so
here is exactly what was and was not fixed.

The parse-failure claim did not hold up. Codex 0.151 accepts legacy
"shell_command" as an alias for "unified_exec", and all four new 0.151 booleans have
deserialization defaults, so the previous catalog output could not fail parsing. That
matches your later comment withdrawing the causal claim. If the original crash is still
reproducible on 2.35.0+, it has a different cause and is worth a fresh report with the
Desktop log.

Two genuine defects were found underneath it, and both are fixed:

hasNativeCatalogRowShape() required shell_type to be exactly "shell_command", so
an authentic Codex 0.151 native row carrying "unified_exec" was rejected outright and
could never be retained as an observed account-bound native model.
The pinned snapshot omitted include_plugin_usage_instructions: true. Codex reads that
value when building world-state instructions, so normal 0.151 native models silently
lost their plugin usage instructions. That is a real behavior regression and the most
user-visible part of what you found.

Generation now canonicalizes the legacy aliases to unified_exec, materializes the four
0.151 booleans with their correct defaults, and accepts both spellings on read. Defaults
apply only where a property is absent, so an explicit per-model value is never
overwritten — that has its own regression test, since it was the main risk in the change.

Thanks for the precise field-level report; the schema diff is what made the plugin-
instructions regression findable at all.

fix(catalog): accept unified_exec rows and restore plugin usage instr…

Navigation Menu

Repository navigation

[Bug][Windows][Codex App] Generated catalog keeps the pre-0.151 schema: shell_type pinned to shell_command, four 0.151 fields never emitted #2896

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Redacted configuration

Suggested fix

리뷰 · 우선순위 71 / 80

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Bug][Windows][Codex App] Generated catalog keeps the pre-0.151 schema: shell_type pinned to shell_command, four 0.151 fields never emitted #2896

Description

Client or integration

Area

Summary

Reproduction

Version

Operating system

Provider and model

Logs or error output

Redacted configuration

Suggested fix

Activity

c040340 commented on Aug 29, 2026

lidge-jun commented on Aug 29, 2026

리뷰 · 우선순위 71 / 80

lidge-jun commented on Aug 29, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions