[Bug][Windows] Stale persisted CLI 0.135.0 strips max/ultra while Codex Desktop runs 0.153.4 #4204

Summary

On Windows, OpenCodex 2.50.0 can strip max and ultra from the shared Codex catalog using a stale standalone CLI, while the running Codex Desktop app uses a newer runtime that supports both. Starting/syncing OpenCodex can therefore remove options that the actual Desktop runtime accepts.

The installed sources for runtime.ts, catalog/bundled.ts, and catalog/effort.ts were verified byte-for-byte against the corresponding Git blobs at upstream HEAD 2d4d7a22381a2e497c2442902104619e25f937c7 during this investigation.

Client / Area / Environment

• Client: Codex App; area: Catalog / models, Windows runtime discovery.
• Windows 11 Pro, build 26200, x64.
• OpenCodex: @bitkyc08/opencodex 2.50.0.
• Installed MSIX: OpenAI.Codex 26.903.9818.0; app.asar package version: 26.903.71938.
• Persisted OpenCodex runtime: %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe, codex-cli 0.135.0, source configured.
• Running Desktop child runtime, verified through the process table: %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe, codex-cli 0.153.4.
• Desktop parent executable: %ProgramFiles%\WindowsApps\OpenAI.Codex_<version>_x64__<publisher>\app\ChatGPT.exe.

Reproduction And Fresh Proof

The existing codex-runtime-clamp.json records removedEfforts: ["max", "ultra"], runtime version 0.135.0, at 2026-09-10T12:01:09.525Z. Affected rows include gpt-6-astra, the GPT-5.6 family, and routed Anthropic models.

A non-mutating probe imported the installed OpenCodex functions supportedCodexReasoningEffortsFromObservedCatalog and clampCatalogModelsToObservedCodexSupport. For each real executable it ran --version and debug models --bundled, then applied the derived support set to the same in-memory GPT-6 Astra row. It did not run live sync or rewrite the user's catalog.

Reproduction shape, with legacyCli and desktopCli set to the two real executable paths:

import { execFileSync } from "node:child_process";
import {
  supportedCodexReasoningEffortsFromObservedCatalog,
  clampCatalogModelsToObservedCodexSupport,
} from "./src/codex/catalog/effort";

for (const exe of [legacyCli, desktopCli]) {
  const bundled = JSON.parse(execFileSync(exe, ["debug", "models", "--bundled"], { encoding: "utf8" }));
  const rows = [{
    slug: "gpt-6-astra",
    default_reasoning_level: "medium",
    supported_reasoning_levels: ["low", "medium", "high", "xhigh", "max", "ultra"].map(effort => ({ effort })),
  }];
  console.log(clampCatalogModelsToObservedCodexSupport(
    rows, supportedCodexReasoningEffortsFromObservedCatalog(bundled),
  ));
}

The user reports disappearing picker options after starting OpenCodex. The full UI/startup sequence was not replayed during this investigation, to avoid restarting an active Desktop session. At inspection time the on-disk catalog already contained max/ultra for Astra and Sol (last write 2026-09-10T12:55:35Z), while the earlier clamp diagnostic remained. Thus that diagnostic is historical evidence, not a claim that the current file still lacks the options. The controlled probe reproduces the destructive projection itself.

OpenCodex Source Trace

1. runtime.ts:576: resolution orders environment, persisted configuration, shim, PATH, fallback. A still-runnable persisted CLI wins even when another runtime is newer. This resolver does not reconcile its choice with the running Desktop child. resolveAndPersistCodexRuntime also persists automatically discovered selections, so configured alone does not establish that the user intentionally pinned an old runtime.
2. catalog/bundled.ts:241: bundled-catalog loading probes the single selected runtime and defaults discoverAlternatives to false.
3. catalog/effort.ts:313: the effort vocabulary is derived from bundled bare native models.
4. catalog/effort.ts:348: unsupported rungs are removed from rows; the list-level helper applies this across models.
5. catalog/sync.ts:1945: sync invokes the clamp. cli/index.ts:488 calls the startup sync gate.

Why This Appears On Windows

The inspected Windows Desktop app and OpenCodex do not share executable discovery. Desktop runs a relocated, hash-addressed runtime under %LOCALAPPDATA%\OpenAI\Codex\bin, while OpenCodex retains a runnable older executable under %LOCALAPPDATA%\Programs\OpenAI\Codex\bin.

The installed Desktop app.asar was read directly, without modifying it. In .vite/build/main-CMBCj4XL.js:1, runtime resolution contains Windows-specific bundled-path and WindowsApps relocation handling (Zr, Qr, $r; relocateWindowsApps). This differs from OpenCodex's persisted/PATH resolver. The process table and both --version probes confirm that these paths actually differ on the affected machine.

This is a Windows packaging/runtime-discovery mismatch, not evidence that Windows cannot support these efforts. The clamp itself is platform-independent, and the same stale-runtime arrangement could affect other OSes. No macOS machine was tested, so strict Windows exclusivity is not established.

Separate Desktop Display Conditions

The installed Desktop renderer also filters efforts independently of the catalog:

• webview/assets/app-initial-f094ef01c64d.js:1, M2i: intersects model effort rows with enabledReasoningEfforts, and removes Ultra when includeUltraReasoningEffort is false.
• The same bundle defines enabled-reasoning-efforts; its default list omits max. Ultra additionally has a feature gate in the model query (1186680773) and a show-ultra-in-model-picker-slider preference defaulting to false.
• webview/assets/agent-settings-bfb770313a62.js:1: the available-efforts settings depend on hasModelSupportingMaxReasoningEffort / hasModelSupportingUltraReasoningEffort. A clamped model list can therefore remove the settings choices themselves.

These are source-observed conditions, not a claim about the affected user's current feature-gate values. They explain why restoring catalog bytes alone is insufficient to guarantee visible controls. No Windows-only max/ultra exclusion was established in these inspected filter functions.

Expected Behavior / Suggested Fix

For Desktop catalog synchronization, detect and report the consuming Desktop runtime and compare it with the selected OpenCodex CLI before destructively reducing the shared catalog. Distinguish explicit runtime pins from automatically persisted discovery. Account for Windows MSIX relocation and process identity; do not simply probe a protected WindowsApps path or silently replace an intentional pin.

Keep old-CLI compatibility handling where it is actually needed. Do not unconditionally enable arbitrary efforts: a newer Desktop and an older CLI may share the catalog, so runtime-specific projections or an explicit mismatch/recovery flow may be necessary. Diagnostics should separate runtime mismatch, catalog clamp, stale Desktop model cache, and renderer visibility preferences/gates.

Regression coverage should include a runnable legacy configured CLI beside a newer MSIX Desktop child, and verify that Desktop synchronization does not silently use the legacy ladder.

Related / Checks

• Related closed issue bug(catalog): clamp in b7ce5aad strips max/ultra from all models regardless of Codex binary version #297 covers the general bundled-ladder clamp; this report adds a reproduced Windows stale-runtime selection mismatch on 2.50.0.
• Related closed issue Windows: model picker stays stale after ocx sync --restart-codex until full desktop app restart #2292 covers stale Windows Desktop model caches. Cache staleness alone cannot explain the recorded clamp or the controlled probe, but remains a separate possible cause of current UI state.
• Existing issues and official configuration documentation were checked. Public documentation alone does not resolve this installed-build runtime mismatch.
• No credentials, account data, user-specific absolute paths, or full proprietary app sources are included.