Windows app 26.707.31428 regression: active GPT-5.6 sessions fall back to "Custom", new sessions lose GPT-5.6 in the picker, and account/workspace state becomes inconsistent

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #32012

Powered by Codex Action

same

I can reproduce this issue on Windows. Additional diagnostics suggest that GPT-5.6 is being removed by the desktop frontend's remotely delivered model
whitelist, rather than by the bundled app-server or model entitlement.

### Environment

• Windows desktop package: OpenAI.Codex 26.707.3748.0
• Desktop bundled runtime: codex-cli 0.144.0-alpha.4
• Standalone CLI: codex-cli 0.144.1
• config.toml model: gpt-5.6-sol

The standalone CLI can see and use GPT-5.6, but the desktop model picker does not show it. A full application restart and Windows reboot did not resolve
the issue.

### Diagnostic evidence

Calling model/list directly on the desktop-bundled app-server returns:

• gpt-5.6-sol: hidden=false, isDefault=true
• gpt-5.6-terra: hidden=false
• gpt-5.6-luna: hidden=false

Therefore, the bundled runtime receives all three GPT-5.6 models and does not mark them as hidden.

Inspecting the desktop renderer shows that it reads Statsig dynamic config 107580212. The current network-fetched configuration is version 22 and
contains:

```json
{
"available_models": [
"gpt-5.5",
"gpt-5.4",
"gpt-5.4-mini",
"gpt-5.3-codex",
"gpt-5.2"
],
"use_hidden_models": true,
"default_model": "gpt-5.4"
}

Because use_hidden_models is enabled, the renderer filters the app-server model list through available_models. None of the GPT-5.6 model IDs are present
in that whitelist, so they are removed from the desktop picker even though model/list returns them with hidden=false.

I also repeated the bundled app-server test using the built-in official OpenAI provider, and it still returned all three GPT-5.6 models. This rules out a
custom inference relay as the source of the whitelist. The Statsig configuration is fetched independently over HTTPS from Statsig CDN endpoints.

The official models documentation currently lists GPT-5.6 Sol, Terra, and Luna as available in the ChatGPT desktop app:

https://developers.openai.com/codex/models

### Likely cause

This appears to be a desktop frontend rollout/configuration issue in Statsig dynamic config 107580212, rather than a local cache, installation,
configuration, bundled CLI, relay, or account entitlement problem.

Could the desktop rollout whitelist be updated to include:

• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.6-luna

Confirming the same behavior with a custom local Responses provider.

Environment:

• Codex Windows App with its backend running in WSL
• Local OpenAI-compatible proxy backed by an API provider
• model_catalog_json contains visible gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna entries
• The Codex CLI can see the 5.6 models

The Windows App picker shows the older catalog models through GPT-5.5, but none of the three GPT-5.6 entries. The configured 5.6 model may instead appear as Custom. Prefixing the catalog display names confirmed that the App reads our custom catalog labels, but it still omitted all 5.6 model IDs. Full App restarts did not change the behavior.

This is consistent with the desktop-side model filtering described above rather than a Responses API or catalog parsing problem.

The comment is sent by an agent, behalf of @Menci.

Confirming your v22 payload from an independent side — same values on a fresh macOS install of 26.707.31428, anonymous session. Adding a length-preserving asar patch that defeats the filter without touching Statsig itself.

Filter location (Codex/ChatGPT.app 26.707.31428, com.openai.codex):

webview/assets/app-initial~app-main~onboarding-page~...~k0ede4gb-C17KDkOa.js:

• $v(e) — zod-parses use_hidden_models, available_models, default_model off the Statsig dynamic-config payload
• ay() — reads eee('107580212').value
• Jv({authMethod:e, availableModels:t, models:a, useHiddenModels:o}) — the picker filter:

``js
let l = o && e !== 'amazonBedrock';
a.forEach(n => { if (l ? t.has(n.model) : !n.hidden) { /* keep */ } });
``

Verify live (paste into DevTools console once you have one on the app):

Object.values(__STATSIG__.instances)[0].getDynamicConfig('107580212').value
// -> { use_hidden_models: true, default_model: 'gpt-5.4',
//      available_models: ['gpt-5.5','gpt-5.4','gpt-5.4-mini','gpt-5.3-codex','gpt-5.2'] }

For any non-ChatGPT-authed session (API-key, Azure, custom OpenAI-compatible) the whitelist branch runs and every hidden:false model that app-server model/list returned — gpt-5.6-{sol,terra,luna} included — gets stripped, even though the CLI running from the same bundle can invoke them fine.

One-byte shim (per-install; gets wiped by Sparkle):

ASAR=/Applications/ChatGPT.app/Contents/Resources/app.asar
OFF=$(grep -aboE 'use_hidden_models' "$ASAR" | head -1 | cut -d: -f1)
printf 'Z' | dd of="$ASAR" bs=1 seek=$((OFF+16)) count=1 conv=notrunc
codesign --force --deep --sign - /Applications/ChatGPT.app

Renames the string literal inside $v() so safeParse(e.use_hidden_models) misses and the field defaults to false. Length-preserving (asar header untouched), idempotent, reversible. Works because EnableEmbeddedAsarIntegrityValidation fuse is OFF on shipped builds.

Fix at the source — any one of these:

1. In Jv/ive: skip the whitelist branch when authMethod !== 'chatgpt'. Custom API-key providers shouldn't be gated by a ChatGPT-account-scoped rollout list.
2. In Jv/ive: union availableModels with models.filter(m => !m.hidden) before the t.has() check, so provider-returned visible models can never be dropped.
3. Server-side: exclude non-ChatGPT-authed sessions from Statsig config 107580212 targeting.

Happy to help verify a fix if useful.

We are also seeing this behaviour and it is stopping our app users from using 5.6.

I can confirm the Statsig configuration is where the models disappear. On macOS Desktop 26.707.31428, a less invasive temporary workaround than modifying app.asar is to launch Codex with a fresh Electron profile and make the Statsig host unreachable only for that process:

open -n "/Applications/Codex.app" --args \
  --user-data-dir="$HOME/Library/Application Support/Codex-unfiltered" \
  --host-resolver-rules="MAP ab.chatgpt.com 127.0.0.1,EXCLUDE localhost"

The fresh profile is important because the normal profile can continue using its cached Statsig payload. With no cached payload and the fetch failing, the renderer falls back to showing models returned by model/list with hidden: false. This restored the GPT-5.6 variants and visible custom-catalog models in the picker.

This is clearly a workaround and may affect other Statsig-controlled features in the isolated profile. However, I think it conclusively demonstrates that config 107580212 is causing the picker filtering: when the app cannot load that configuration and has no cached copy, the models appear.

I think I found a workaround:

1. Open the menu in the upper-left corner and switch from Codex to Work (see image below).

<img width="306" height="210" alt="Image" src="https://github.com/user-attachments/assets/a41f530d-8e0b-459d-98c5-3a1d069b61f6" />

1. In Work, select a GPT‑5.6 model.
2. Switch back to Codex. GPT‑5.6 should now appear there.

A possible fix is to remove a stale CODEX_CLI_PATH environment override, which can make the Windows app use an older standalone Codex runtime instead of its bundled one.

Run in PowerShell:

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")
Remove-Item Env:CODEX_CLI_PATH -ErrorAction SilentlyContinue

Then fully close and reopen the ChatGPT/Codex app. This fixed the missing GPT‑5.6 models for me without resetting or reinstalling the app.

Closing this issue because the original blocking symptom is no longer present in my current environment: the GPT-5.6 entries are visible again in the Codex app model picker.

This closure means the issue is resolved for my account/environment and is no longer reproducible for me. It does not claim that the underlying Statsig/rollout inconsistency has been independently confirmed as fixed globally; other users may still be affected. If the problem returns, I can reopen the issue with updated app-version and account/workspace evidence.