Connect with ChatGPT omits Codex models available through CLI login

[xHeaven]

What happened

The new "Connect with ChatGPT" login shows fewer Codex models than the existing CLI login in T3 Code's desktop app connected to its local server.

The affected managed provider is "Personal". Its saved model list contains six models; "Codex - CLI" contains nine. GPT-6.1-Sol, GPT-6-Sol, and GPT-6-Luna are missing from Personal, while GPT-6-Astra appears in both.

I also tried adding the missing models through T3 Code's built-in custom-model configuration. The reasoning tiers and Fast/Standard speed tiers do not appear in the picker, even though I configured those options for the custom models. This prevents the custom-model setup from restoring the controls available through the CLI provider.

Diagnosis

The two login methods use different model catalogs:

• apps/server/src/provider/CodexChatGptModels.ts requests https://api.openai.com/v1/models with the managed account's subscription-sharing access token, then includes only entries with visibility === "list".
• apps/server/src/provider/Drivers/CodexManagedProvider.ts replaces the native model list with that result. Native Codex entries contribute capability metadata but cannot add model choices.
• Personal's native Codex caches contain all three missing models. Their presence there does not establish access through subscription sharing.
• The installed desktop server bundle contains the same catalog logic as release tag v0.0.44 at 451afcb22d93f06cb24f9bc16703404564952553. The loader remains unchanged on upstream main at ff1db030b179ef712cacc0098366d976e2877f45.

This follows OpenAI's documented catalog discovery, which distinguishes current account-specific choices from Codex's bundled or cached list. Please clarify whether these models are intentionally unavailable through ChatGPT subscription sharing or whether catalog discovery needs correction.

The managed-provider code also clears customModels when building its pending snapshot and removes the serviceTier capability descriptor from returned models. The service-tier removal is explicit, and #14304 describes it as intentional for managed ChatGPT connections. This is relevant to the attempted custom-model workaround, but does not establish why configured reasoning tiers were absent. The custom-model configuration and picker behavior were user-reported and were not independently reproduced during triage. Please clarify which custom-model controls are supported for this connection method.

Limits of the diagnosis: the raw /v1/models response was not captured, so absent entries cannot be distinguished from entries with non-list visibility. Personal was disabled by the time of triage, and its current snapshot has unknown authentication status. An earlier user-supplied investigation reported the same account email and Codex 0.159.0 for both logins; this triage could not independently reverify Personal's account identity. No fresh same-account inference comparison was performed.

Steps to reproduce

1. Open the T3 Code desktop app connected to its local server, with an existing authenticated Codex CLI provider.
2. Add a provider through "Connect with ChatGPT" and name it Personal.
3. Compare the model choices for Personal and Codex - CLI.
4. On this installation, CLI lists nine models while Personal lists six, excluding gpt-6.1-sol, gpt-6-sol, and gpt-6-luna.
5. Try adding those models through the built-in custom-model configuration, including reasoning tiers and Fast/Standard speed tiers.
6. The configured reasoning and speed controls do not appear in the picker, as reported by the user.

These are the reported UI steps, corroborated by saved provider catalogs. A fresh login reproduction is still needed.

Version

Desktop package: 0.0.44-nightly.20260929.2456. Generated CLI triage context reports 0.0.44.

Environment

macOS, Darwin 27.0.0, arm64; Node v26.8.2; Codex 0.159.0; desktop app against its local server.

Evidence

Selected non-sensitive fields from the saved catalogs and native caches:

Codex - CLI: 9 models
  gpt-6.1-sol, gpt-6-astra, gpt-6-sol, gpt-6-luna,
  gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna,
  gpt-daybreak-blue-latest, gpt-5.5

Personal: 6 models
  gpt-6-astra, gpt-5.6-sol, gpt-5.6-terra,
  gpt-5.6-luna, gpt-daybreak-blue-latest, gpt-5.5

Personal native models_cache.json, client_version 0.159.0:
  gpt-6.1-sol, gpt-6-sol, and gpt-6-luna are present
  in both shared-home and shadow-home caches.

Server traces contain 33 successful chatGptModels spans.
These spans do not identify the provider or record response models.

Related issues

• #14290 introduced managed ChatGPT authentication and this catalog loader.
• #14301 concerns GPT-6.1-Sol being categorized as legacy. Here it is absent from the affected provider's saved list, so this is a different symptom.
• #14304 fixes Pro Max plan decoding and CLI Ultrafast availability, not this catalog difference.

No matching issue or newer released fix was found during triage.

Fix applied or workaround

The existing Codex - CLI provider lists the missing models and is available as a workaround. No new inference request was run to verify them.

The user had already attempted the built-in custom-model workaround, but its configured reasoning tiers and Fast/Standard speed tiers did not appear. No configuration, database, cache, or source changes were applied by the triage agent.

Filed by

Codex, GPT-6 model family, via the T3 Code triage playbook.

[juliusmarminge]

Triage

The smaller Personal list is the ChatGPT account catalog. The Codex CLI list is Codex’s cached model/list. Those are different sources, and the managed picker is doing what it was built to do.

chatGptModels in apps/server/src/provider/CodexChatGptModels.ts requests https://api.openai.com/v1/models and keeps rows with visibility == "list". That matches OpenAI’s subscription-sharing catalog. Native Codex entries are only capability metadata, matched by slug. A slug in models_cache.json is not added to the picker. The catalog test covers this: a cached model that OpenAI does not return as list-visible stays out.

Personal’s saved snapshot has six models, so discovery succeeded. A failed decode does not return a partial list. makeManagedCodexProvider catches that and publishes models: [] with “Could not check Codex right now.” Six models means those six were the list-visible rows. gpt-6.1-sol, gpt-6-sol, and gpt-6-luna were missing from that response or not marked visibility: "list". There is no slug blocklist. gpt-6-astra is in both catalogs, so this is not a GPT-6 filter.

Nothing in a newer T3 build adds those three until OpenAI returns them as list-visible. The existing Codex CLI provider is the way to use them.

Two separate facts about the custom-model attempt:

• Reasoning controls are a bug on this connection. Settings stores the descriptors, and the picker will show the extra slug from providerInstances[].config.customModels. The traits menu does not read that config. It uses the server snapshot (selectedProviderEntry.models in ChatComposer). The managed snapshot never includes custom models: the pending snapshot is built with customModels: [], and the authenticated snapshot replaces models with the ChatGPT catalog. turn/start will still send a custom slug, and it will send reasoningEffort only when that option is on the selection. With no traits menu, the effort is never attached.
• Fast/Standard is intentional. The managed snapshot strips every serviceTier descriptor, and CodexAdapter.sendTurn skips the service tier whenever the managed runtime is attached. #14304 already records that speed tiers, including Ultrafast, stay on the CLI login. A custom Speed option cannot bring them back.

Listed models that also exist in the native Codex cache, including gpt-6-astra, should still show reasoning. They should not show a speed tier.

The catalog gap does not need a code change. The bug is custom-model reasoning descriptors on a managed ChatGPT instance never reaching the picker.

[kvnloo]

For the remaining custom-model reasoning bug, there is already a narrow server-side seam we can reuse instead of teaching the picker to read provider config.

CodexProvider.ts has appendCustomCodexModels(models, customModels): explicit custom capabilities win, and bare custom slugs borrow the native fallback descriptors. Managed Codex currently opts out twice: the pending snapshot calls makePendingCodexProvider({ ...config, customModels: [] }), and the authenticated path replaces models with the ChatGPT catalog.

A small shape would be to extract/reuse that helper after chatGptModels(...), passing the managed instance's configured custom models, then run the existing managed serviceTier filter over the combined list. That preserves Julius's catalog boundary (custom slugs do not pretend to be list-visible ChatGPT models) while allowing configured reasoning descriptors through; Fast/Standard still stays intentionally stripped.

Regression I'd add: managed catalog has gpt-6-astra; config adds a custom slug with a reasoningEffort descriptor plus serviceTier. Snapshot contains the custom slug + reasoning descriptor, but no serviceTier descriptor.

[braziliansalsa]

Confirming on Windows, v0.0.44 (451afcb), desktop app with local server, codex-cli 0.159.1.

Provider status caches on this machine:

Provider	Models
Codex (CLI login)	gpt-6.1-sol, gpt-6-astra, gpt-6-sol, gpt-6-luna, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5, with reasoningEffort and serviceTier options
ChatGPT connection (managed)	gpt-6-astra, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5, with only reasoningEffort

It's the same gap reported here: gpt-6.1-sol, gpt-6-sol and gpt-6-luna are missing, and so is the Fast/Standard speed option. Updating the ChatGPT desktop app and refreshing the provider didn't change the managed list.

Filed by Claude Code (Claude Opus 5.5) via t3 triage

[vertopolkaLF]

Confirming the catalog gap on another Windows installation, now with Codex CLI 0.159.2.

• T3 Code desktop app, version 0.0.44 (451afcb22d93), Windows x64. The desktop backend was running locally.
• The managed ChatGPT provider's saved status snapshot was ready at 2026-09-30T20:54:14Z and listed exactly five models: gpt-6-astra, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5. The model picker screenshot showed the same five.
• The Codex CLI provider's saved status snapshot was ready at 2026-09-30T20:59:23Z with CLI version 0.159.2 and listed eight models: gpt-6.1-sol, gpt-6-astra, gpt-6-sol, gpt-6-luna, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, gpt-5.5.

The snapshots were taken at different times, after the user changed which provider was enabled; this is a saved-catalog comparison, not a simultaneous fresh response capture. I did not inspect the raw ChatGPT /v1/models response or independently verify both providers use the same account. No configuration, database, cache, or source changes were made by this triage agent.

Observed via the T3 Code triage playbook by Codex (GPT-6-Astra).