Repository navigation
Connect with ChatGPT omits Codex models available through CLI login #14321
Description
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.tsrequestshttps://api.openai.com/v1/modelswith the managed account's subscription-sharing access token, then includes only entries withvisibility === "list".apps/server/src/provider/Drivers/CodexManagedProvider.tsreplaces 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.44at451afcb22d93f06cb24f9bc16703404564952553. The loader remains unchanged on upstream main atff1db030b179ef712cacc0098366d976e2877f45.
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
- Open the T3 Code desktop app connected to its local server, with an existing authenticated Codex CLI provider.
- Add a provider through "Connect with ChatGPT" and name it Personal.
- Compare the model choices for Personal and Codex - CLI.
- On this installation, CLI lists nine models while Personal lists six, excluding
gpt-6.1-sol,gpt-6-sol, andgpt-6-luna. - Try adding those models through the built-in custom-model configuration, including reasoning tiers and Fast/Standard speed tiers.
- 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.
Activity
juliusmarminge commentedon Sep 29, 2026
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.chatGptModelsinapps/server/src/provider/CodexChatGptModels.tsrequestshttps://api.openai.com/v1/modelsand keeps rows withvisibility == "list". That matches OpenAI’s subscription-sharing catalog. Native Codex entries are only capability metadata, matched by slug. A slug inmodels_cache.jsonis 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.
makeManagedCodexProvidercatches that and publishesmodels: []with “Could not check Codex right now.” Six models means those six were the list-visible rows.gpt-6.1-sol,gpt-6-sol, andgpt-6-lunawere missing from that response or not markedvisibility: "list". There is no slug blocklist.gpt-6-astrais 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:
providerInstances[].config.customModels. The traits menu does not read that config. It uses the server snapshot (selectedProviderEntry.modelsinChatComposer). The managed snapshot never includes custom models: the pending snapshot is built withcustomModels: [], and the authenticated snapshot replacesmodelswith the ChatGPT catalog.turn/startwill still send a custom slug, and it will sendreasoningEffortonly when that option is on the selection. With no traits menu, the effort is never attached.serviceTierdescriptor, andCodexAdapter.sendTurnskips 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 commentedon Sep 29, 2026
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.tshasappendCustomCodexModels(models, customModels): explicit custom capabilities win, and bare custom slugs borrow the native fallback descriptors. Managed Codex currently opts out twice: the pending snapshot callsmakePendingCodexProvider({ ...config, customModels: [] }), and the authenticated path replacesmodelswith 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 managedserviceTierfilter 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 areasoningEffortdescriptor plusserviceTier. Snapshot contains the custom slug + reasoning descriptor, but noserviceTierdescriptor.braziliansalsa commentedon Sep 29, 2026
Confirming on Windows, v0.0.44 (451afcb), desktop app with local server, codex-cli 0.159.1.
Provider status caches on this machine:
reasoningEffortandserviceTieroptionsreasoningEffortIt'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 commentedon Sep 30, 2026
Confirming the catalog gap on another Windows installation, now with Codex CLI
0.159.2.0.0.44(451afcb22d93), Windows x64. The desktop backend was running locally.readyat2026-09-30T20:54:14Zand 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.readyat2026-09-30T20:59:23Zwith CLI version0.159.2and 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/modelsresponse 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).
bolexyro commentedon Oct 7, 2026
A solution I found was to add another codex provider and configure manually rather than use sign in with chatgpt
Project516 commentedon Oct 19, 2026
Note
Written by an AI agent on behalf of @Project516, from this machine's state and the source.
Another case, on T3 Code 0.1.0 (Linux arm64) with Codex CLI 0.156.1. Here
gpt-6.1-soldoes show up for the managed ChatGPT provider, but with no reasoning selector.The managed catalog lists the model, but the native Codex
models_cache.jsonin the managed shadow home has nogpt-6.1-solentry (its slugs are gpt-6-astra, gpt-6-sol, gpt-reserve, gpt-6-luna, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, codex-auto-review). Native entries are the only source of capability metadata, somapCodexModelCapabilitiesgets nosupportedReasoningEffortsand emits no reasoning descriptor. The manifest entry forgpt-6.1-solhas no capabilities to fall back on.#17865 (keep reasoning choices from the account catalog) would fix this. Until then, updating the Codex CLI to a version whose catalog knows the model should restore the selector.
juliusmarminge commentedon Oct 22, 2026
Checked main at 89fe509232. Read the existing triage and searched open issues and PRs; no duplicate of the full report found. The account-catalog reasoning fallback already has open work in #17865, so I did not open a competing PR.
A fresh same-account UI reproduction is blocked here: the available Codex login uses API-key mode, without ChatGPT OAuth tokens. No authenticated catalog request or browser reproduction was run. Source inspection alone does not establish current account availability.
For the remaining custom-model reasoning symptom, please provide the custom-model configuration with secrets removed, the current T3 and Codex versions, and whether the reasoning selector is still absent. For the catalog difference, a fresh same-account comparison including only model IDs and visibility values from the managed catalog would distinguish account availability from a discovery bug. Do not include tokens, authorization headers, or credential files. The intentional speed-tier restriction is separate, as noted in the maintainer comment above.