[Windows Desktop] GPT-6 Astra missing from model picker for eligible ChatGPT Pro account

What version of the Codex App are you using (From “About Codex” dialog)?

Windows installed package: OpenAI.Codex_26.901.4073.0_x64__2p2nqsd0c76g0

Bundled runtime: codex-cli 0.153.1

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

GPT-6 Astra is available in ChatGPT Work on the web for this account, but it is absent from the model picker in Codex Desktop on Windows for the same signed-in account.

The account is recognized as planType: pro by Codex. GPT-5.5 and GPT-5.6-family models are available in the desktop picker, but gpt-6-astra is not offered.

This persists after signing out and back in, fully exiting Codex, confirming that no codex.exe or codex-code-mode-host.exe processes remain, relaunching the app, and creating a new task.

What steps can reproduce the bug?

Sign in to ChatGPT Work on the web with the affected ChatGPT Pro account.
Confirm that GPT-6 Astra is available there.
Sign in to Codex Desktop on Windows with the same account.
Create a new Codex task and open the model picker.
Observe that GPT-6 Astra is absent.
Sign out of Codex Desktop, fully exit the app, terminate any remaining Codex background processes, relaunch, sign in again, and create another new task.
Observe that GPT-6 Astra remains absent.

No session ID is included because the problem affects the account-level model picker across newly created tasks, rather than one inference session.

What is the expected behavior?

GPT-6 Astra should appear in the Codex model picker for the eligible ChatGPT Pro account, consistent with its availability in ChatGPT Work and the announced availability for all Pro users in Work and Codex.

Additional information

The installed client appears new enough to understand Astra:

Backport GPT-6-Astra model catalog to 0.153 #42605 backported the GPT-6 Astra model catalog to the 0.153 release line for 0.153.1.
The bundled Astra entry declares minimal_client_version: 0.153.0, supported_in_api: true, and visibility: hide.
The affected installation runs codex-cli 0.153.1.

This suggests that the client contains the Astra definition but the account-specific or remotely supplied Codex catalog is not making it visible. No exact duplicate matching this Pro + Work available + Windows Codex picker missing case was found before filing.

Related announcement: https://x.com/sama/status/2095973658867171733

Related catalog backport: #42605

Additional diagnostic result: direct model invocation succeeds on the same installation and account.

Command shape used:

codex exec --ephemeral --skip-git-repo-check --ignore-user-config --model gpt-6-astra --sandbox read-only "Respond with exactly ASTRA_OK and do not call tools."

Observed result:

Codex reported model: gpt-6-astra and provider: openai.
The model returned exactly ASTRA_OK.
Process exit code was 0.

This narrows the issue: the account and backend permit gpt-6-astra, and the installed 0.153.1 runtime can run it successfully. The failure is limited to discovery/visibility in the Windows Desktop model picker rather than model entitlement or inference access.

is this the latest code version?

if it is still missing - I recomend you restart the codex app / cli

if you see "update" button please update - we had'se it in the past - where you need to update for it to appear.

Experiencing this on Fedora with Codex CLI 0.153.3, when trying to force it with codex -m gpt-6-astra I just get told to update my codex installation.

Same issue with Codex CLI 0.153.4 (latest) on macOS.

$ codex --version
codex-cli 0.153.4

$ codex exec --ephemeral --skip-git-repo-check --ignore-user-config --model gpt-6-astra --sandbox read-only "Respond with exactly ASTRA_OK and do not call tools."
OpenAI Codex v0.153.4
--------
workdir: [...]
model: gpt-6-astra
provider: openai
approval: never
sandbox: read-only
reasoning effort: none
reasoning summaries: none
session id: [...]
--------
user
Respond with exactly ASTRA_OK and do not call tools.
codex
ASTRA_OK
tokens used
4,196

Starting codex normally, gpt-6-astra does not show up in the/model picker.

Running codex -m gpt-6-astra and typing in a prompt results in:

⚠ Model metadata for `gpt-6-astra` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.

■ {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-6-astra' model requires a newer
version of Codex. Please upgrade to the latest app or CLI and try again."}}

Confirmed to be still broken on macOS for v0.153.4
OpenAI devs: Please do not close this issue until users can confirm it is resolved.

I deleted my .codex folder and did a fresh install now it shows GPT-6-Astra properly in the model picker:

I managed to get Codex CLI on macOS working without a full delete of the.codex folder.

First, find the PID of the running Codex app server:

$ ps -ef | grep codex | grep app-server

Then kill it, delete the model cache, and restart the app server:

$ kill -TERM <pid>
$ rm ~/.codex/models_cache.json
$ codex app-server daemon start

I managed to get Codex CLI on macOS working without a full delete of the.codex folder.

First, find the PID of the running Codex app server:
$ ps -ef | grep codex | grep app-server
Then kill it, delete the model cache, and restart the app server:
$ kill -TERM <pid>
$ rm ~/.codex/models_cache.json
$ codex app-server daemon start

This worked for me as well for Windows codex remote SSH sessions to linux hosts.

I managed to get Codex CLI on macOS working without a full delete of the.codex folder.
First, find the PID of the running Codex app server:
$ ps -ef | grep codex | grep app-server
Then kill it, delete the model cache, and restart the app server:
$ kill -TERM <pid>
$ rm ~/.codex/models_cache.json
$ codex app-server daemon start
This worked for me as well for Windows codex remote SSH sessions to linux hosts.

alternative would be restarting your computer perhaps?

Follow-up from another affected Windows Desktop environment:

Codex Desktop: 26.901.6511.0
Bundled CLI: 0.153.4
Subscription/auth: ChatGPT Pro via ChatGPT sign-in

I tested the targeted model-cache workaround by moving only ~/.codex/models_cache.json aside and fully restarting Codex Desktop. After restart, the cache file was not recreated, and codex debug models exited successfully but still omitted gpt-6-astra while listing the GPT-5.6 Sol/Terra/Luna models.

A minimal direct invocation on the same installation and account succeeded:

codex exec --ephemeral --skip-git-repo-check --ignore-user-config --model gpt-6-astra --sandbox read-only "Respond with exactly ASTRA_OK and do not call tools."

Observed result:

reported model: gpt-6-astra
provider: openai
response: exactly ASTRA_OK
exit code: 0

This confirms that the account/backend entitlement and the bundled 0.153.4 runtime can execute Astra. The remaining failure is model discovery/visibility in the Desktop picker/catalog. The targeted models_cache.json reset did not resolve it in this environment.

codex exec --ephemeral --skip-git-repo-check --ignore-user-config --model gpt-6-astra --sandbox read-only "Respond with exactly ASTRA_OK and do not call tools."
OpenAI Codex v0.145.0

workdir: redacted
model: gpt-6-astra
provider: openai
approval: never
sandbox: read-only
reasoning effort: none
reasoning summaries: none
session id: 01a07522-48ee-7dd1-bf39-fed756a0345e

user
Respond with exactly ASTRA_OK and do not call tools.
warning: Model metadata for gpt-6-astra not found. Defaulting to fallback metadata; this can degrade performance and cause issues.
ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-6-astra' model requires a newer version of Codex. Please upgrade to the latest app or CLI and try again."}}
ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-6-astra' model requires a newer version of Codex. Please upgrade to the latest app or CLI and try again."}}

But my macOS desktop app is up to date

/Applications/ChatGPT.app/Contents/Resources/codex exec \
--ephemeral
--skip-git-repo-check
--ignore-user-config
--model gpt-6-astra
--sandbox read-only
"Respond with exactly ASTRA_OK and do not call tools."
OpenAI Codex v0.153.4

workdir: redacted
model: gpt-6-astra
provider: openai
approval: never
sandbox: read-only
reasoning effort: none
reasoning summaries: none
session id: 01a0752b-01da-7711-8441-e2431203c3ce

user
Respond with exactly ASTRA_OK and do not call tools.
codex
ASTRA_OK
tokens used
5,932

Still not visible in the macOS desktop app

Found the issue, i had a config.toml in which the model_catalog_json was set, and it was set to a json that did not contain astra, therefore it was not visible anywhere. My "old" codex home for the cli was also updated to the latest version

I found a concrete Windows-specific cause for this symptom that may help others diagnose it.

Environment

Codex Desktop for Windows: 26.901.6511.0
ChatGPT Pro account
The same account already had GPT-6 Astra available on macOS
Astra was missing only from the Windows Desktop model picker

Root cause

A user-level CODEX_CLI_PATH environment variable was still set from an older standalone/custom Codex setup.

Process inspection confirmed that Codex Desktop was actually launching the executable referenced by CODEX_CLI_PATH for its app-server, instead of using the current bundled Desktop runtime.

The overridden CLI reported:

codex-cli 0.151.0-alpha.7.2

So although the installed Windows Desktop package itself was current, the effective runtime used by Desktop was much older.

Resolution

Removed the user-level CODEX_CLI_PATH override.
Terminated the running Codex/ChatGPT Desktop processes.
Relaunched the Windows app so it could use its bundled runtime.

After relaunch, GPT-6 Astra appeared immediately in the Windows model picker.

Suggested diagnostic / UX improvement

For Windows users who have a current Desktop build but are missing newer models, it may be worth checking whether CODEX_CLI_PATH is overriding the bundled runtime.

It would also be useful if the Desktop About/diagnostics UI showed the effective CLI path and version actually used by the app-server, and warned when an external CODEX_CLI_PATH override is active. That would make this class of version-skew issue much easier to identify.

I have intentionally omitted local paths, usernames, and machine-specific details.

Confirmed fix on Windows.
Root cause in my case was a stale user-level CODEX_CLI_PATH override. Even though:

ChatGPT Desktop was up to date
codex --version returned 0.154.0
Astra worked in ChatGPT Work on the web
the Desktop app still did not show GPT-6 Astra.
This command revealed the override:

[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")

It pointed to:

C:\Users\Administrator\AppData\Local\OpenAI\Codex\bin\codex.exe

I removed it with:

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")

After fully restarting the app / Windows session, GPT-6 Astra appeared in the model picker immediately.
So this was a runtime override issue, not an entitlement or model-cache issue.

Final follow-up from my Windows Desktop / ChatGPT Plus repro: this is now resolved on my machine, and I found a more specific failure mode that may help others.

Before the fix

Windows Desktop package was 26.903.9818.0.
Effective Desktop core was codex-cli 0.153.4.
CODEX_CLI_PATH was unset at user, machine, and process scope.
No model_catalog_json override was present.
The active model catalog cache was stale: models_cache.json dated 2026-08-05, with client_version: 0.146.0, and it did not contain gpt-6-astra.
gpt-6-astra was usable on a separate Linux CLI with the same ChatGPT account, so entitlement/inference access was not the issue.

One important detail: my actual CODEX_HOME was a custom user-level location (F:\CodexData\home), not the default %USERPROFILE%\.codex. That matters because the live cache/config/state were under that custom home.

What changed

After the Desktop/runtime refresh, the installed app/core became:

Desktop: 26.908.4834.0
bundled/effective core: 0.154.0-alpha.6.2

At that point GPT-6 Astra appeared normally in the Desktop model picker.

However, the updated runtime exposed a separate config compatibility problem: the existing config.toml under the active CODEX_HOME failed to load, and Desktop showed a Windows configuration-load error; existing conversations could not be opened.

codex doctor --json reported:

config.load: fail
summary: config could not be loaded

The thread/session data itself was still present and healthy.

Safe recovery path that worked

I did not delete the whole .codex / CODEX_HOME directory.

Backed up the active CODEX_HOME.
Temporarily moved only config.toml aside.
codex doctor --json immediately changed to:

config.load: ok
state DB integrity: ok
thread history DB integrity: ok

Old threads then complained that their stored providers were missing (Model provider 'custom' not found).
I created a minimal replacement config.toml containing only the provider definitions needed by existing threads:

[model_providers.custom]
# existing provider settings

[model_providers.opencode_go]
# existing provider settings

[model_providers.opencode_go.auth]
# existing auth settings

codex doctor --json remained config.load: ok.
Existing conversations opened normally again.
GPT-6 Astra remained visible in the Desktop picker.

What this suggests

For this Windows case, the original Astra issue was consistent with a stale model catalog/cache associated with an old reported client version, despite the effective core already being new enough. The later Desktop/runtime refresh fixed Astra visibility, but the new runtime also exposed an unrelated/adjacent compatibility problem in the existing user config.

It would be useful if Desktop exposed these directly in diagnostics/UI:

effective CODEX_HOME
effective core/app-server executable + version
model catalog cache path and its client_version
whether the picker is using a cached vs freshly fetched catalog

Also, I would strongly avoid recommending deletion of the entire .codex / CODEX_HOME directory as the first recovery step, because that directory can contain thread/session/state data. A targeted catalog-cache refresh plus config validation is much safer.

One remaining doctor warning on my machine is that some rollout files are missing corresponding rows in the state DB (97 active, 16 archived), but the files themselves exist and both the state DB and thread-history DB pass integrity checks. I have intentionally not modified the SQLite state because the app is now functioning normally.

Still reproducible for me on Windows as of 2026-09-15 with the current desktop build.

Environment

ChatGPT Pro
Windows desktop app: 26.908.70816
About dialog says this build was released 2026-09-14
Check for Updates reports: ChatGPT is up to date

Same account, different surfaces

ChatGPT web → Work: GPT-6 Astra is visible and selectable.
Mobile: Astra is available.
Windows ChatGPT desktop → Work: Astra is missing; picker shows GPT-5.6 Sol / Terra / Luna / GPT-5.5.
Windows Codex desktop surface: Astra is also missing from the model picker.

The Windows-only failure has persisted continuously since at least Sep 13. This strongly isolates the problem from account-wide rollout/entitlement: the exact same Pro account already has Astra on web and mobile, while the current Windows desktop app does not expose it in either Work or Codex.

I also have an OpenAI Support case for this (#14791657, later reply showed #15118879) and have supplied screenshots of the web picker, both Windows pickers, About dialog, and the up-to-date confirmation.

Given the diagnostics already discussed in this thread around stale relocated runtimes / CODEX_CLI_PATH, it would be very useful if Desktop exposed the effective app-server/CLI path and version actually in use, not only the shell build in About. I can provide read-only diagnostics if maintainers specify the exact checks they want.

Confirmed root cause + persistent workaround on my Windows Pro setup.

A/B result

With a user-level CODEX_CLI_PATH set to an old npm-installed CLI:

ChatGPT Desktop shell was current.
Desktop launched the overridden npm runtime as its child app-server.
Effective runtime was codex-cli 0.151.0.
GPT-6 Astra was missing from Windows Work/Codex.

After removing only the user-level CODEX_CLI_PATH override and restarting Windows / launching ChatGPT normally from the pinned shortcut:

Astra appeared and remained available.
Desktop now launches its own relocated runtime from:
C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\eab8377aebac6c07\codex.exe
Effective runtime is now:
codex-cli 0.155.0-alpha.2.6

Process evidence after the fix:

Name: codex.exe
Parent: ChatGPT.exe
ExecutablePath:
C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\eab8377aebac6c07\codex.exe

codex-cli 0.155.0-alpha.2.6

This is a clean A/B:

CODEX_CLI_PATH -> old npm Codex 0.151.0 -> Astra hidden
no CODEX_CLI_PATH -> Desktop bundled/relocated Codex 0.155.0-alpha.2.6 -> Astra visible

The npm Codex installation itself did not need to be removed; removing the stale Desktop override was sufficient.

Suggested product fix

Desktop should validate the effective app-server runtime actually being launched. If CODEX_CLI_PATH points to a runtime older than the minimum needed for the current model catalog, it should warn clearly or fall back to the bundled runtime instead of silently hiding newer models.

It would also help if About/Diagnostics displayed the effective app-server path + version, not only the shell/app version.

Follow-up after the latest Windows Desktop update: the update still did not self-heal this condition on my machine. I had to repair it manually.

Current state after the update:

Windows Desktop package actually running: OpenAI.Codex_26.911.7940.0_x64__2p2nqsd0c76g0
ChatGPT Pro
Astra was already available for the same account on Web and Mobile
Before the repair, Desktop still inherited a persistent user-level CODEX_CLI_PATH and launched the old npm CLI as its app-server
Old effective runtime: codex-cli 0.151.0
Result: GPT-6 Astra missing from Windows Work/Codex
After removing the persistent override, normal Desktop startup uses its bundled/relocated runtime:
%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe
Effective bundled runtime after repair: codex-cli 0.155.0-alpha.2.6
Result: GPT-6 Astra appears immediately and remains available after reboot + normal pinned-shortcut launch

So the new Desktop update did not fix the upgrade/migration path. The shell was current, but Desktop could still silently run a stale external core because of an old persistent environment override.

Fully reproduced A/B

Broken state

Persistent user env:

[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")

returned the old npm-native Codex executable. Process inspection then showed the current ChatGPT.exe spawning that old executable directly as:

codex.exe -c features.code_mode_host=true app-server ...

and:

& $p.ExecutablePath --version

returned:

codex-cli 0.151.0

Astra was missing.

Reversible A/B test

I first removed the override only from the current PowerShell process, without modifying the persistent user setting, then launched Desktop from that clean environment.

In that run Desktop selected:

%LOCALAPPDATA%\OpenAI\Codex\bin\eab8377aebac6c07\codex.exe
codex-cli 0.155.0-alpha.2.6

and Astra appeared.

Closing Desktop and launching it again through the normal shortcut while the persistent user variable still existed caused the old behavior to return. That isolated the variable as the cause.

Permanent recovery performed

The persistent user-level override was then removed:

$oldCodexCliPath = [Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")

[Environment]::SetEnvironmentVariable(
    "CODEX_CLI_PATH",
    $null,
    "User"
)

Remove-Item Env:CODEX_CLI_PATH -ErrorAction SilentlyContinue

Then Windows was rebooted so Explorer / pinned shortcuts inherited the clean environment.

Post-reboot verification:

[PSCustomObject]@{
    Process = $env:CODEX_CLI_PATH
    User    = [Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")
    Machine = [Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "Machine")
} | Format-List

Result:

Process :
User    :
Machine :

Then, after launching Desktop normally and starting a Codex/Work task:

$p = Get-CimInstance Win32_Process -Filter "Name='codex.exe'" |
    Where-Object { $_.ParentProcessId -in (Get-Process ChatGPT).Id } |
    Select-Object -First 1

$p.ExecutablePath
& "$($p.ExecutablePath)" --version

Result:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\eab8377aebac6c07\codex.exe
codex-cli 0.155.0-alpha.2.6

Astra is now present in the Windows picker.

No .codex deletion, cache wipe, app-data reset, plugin reset, or reinstall was required.

Standalone CLI is independent and healthy

I also updated the global npm CLI separately:

npm install -g @openai/codex@latest
codex --version
npm list -g @openai/codex --depth=0

Current standalone CLI:

codex-cli 0.154.0
@openai/codex@0.154.0

The native npm executable also works directly and through Node when addressed by its absolute path. This confirms that the correct architecture is:

Desktop -> bundled Desktop runtime
standalone terminal `codex` -> global npm runtime
plugin-specific runtime override -> only that plugin/process, if needed

Desktop should not silently become coupled to a mutable global npm installation just because a persistent CODEX_CLI_PATH exists.

What I think the Desktop updater/startup migration should do

I am not suggesting that the updater literally shell out to PowerShell. The updater/Desktop startup should implement the equivalent checks natively.

On update/startup:

Read whether CODEX_CLI_PATH is active at Process/User/Machine scope.
Resolve the effective app-server executable that Desktop is about to launch.
Probe its actual CLI version.
Compare it with the bundled Desktop runtime / minimum supported client version.
If the external override is stale or incompatible, do not silently launch it.
Prefer/fall back to the bundled Desktop runtime and show a clear warning explaining that an external override was ignored.
Optionally offer a one-click migration/removal of the persistent user override, rather than deleting it silently (it may be used by some external workflow).
Show the effective app-server path + version in About/Diagnostics.

At minimum, Desktop should never display itself as fully up to date while actually running an older external core without any warning.

A robust invariant would be:

Desktop shell is current
+ external CODEX_CLI_PATH points to older/incompatible runtime
=> use bundled runtime (or block with a visible actionable warning)
=> never silently downgrade the effective core

Why this matters for the update experience

Right now an affected Windows user has essentially two choices:

destructive troubleshooting such as deleting .codex, resetting/reinstalling the app, and potentially losing/reconfiguring local state, plugins, settings, or workflow setup; or
manually discover process ancestry, environment-variable precedence, the actual spawned app-server, and repair the environment from PowerShell.

Neither is a reasonable recovery path for a normal paid user, especially because the application itself says it is up to date.

This is an upgrade/migration bug, not an account-entitlement problem. On my account Astra was available on Web/Mobile the whole time. Windows Desktop alone stayed on the stale runtime until I manually corrected the environment.

I also opened Support cases #14791657 / #15118879. The responses focused on gradual rollout / waiting, while the actual cause on this machine was deterministic and local. A couple of banked resets do not restore days of lost access to the advertised model, and they do not address the underlying product failure.

I would strongly recommend shipping this as an actual Desktop updater/startup fix rather than leaving the PowerShell workaround for users to discover in GitHub comments. The updater already owns the version transition; it is the right place to validate the effective runtime and migrate or reject stale overrides.

If maintainers want, I can provide the exact before/after process trees and additional read-only diagnostics, but the A/B above is deterministic on this machine.

Confirming the same Windows Desktop Astra-visibility issue on a ChatGPT Plus account, on a newer desktop build.

Environment

ChatGPT plan: Plus
Authentication: ChatGPT account sign-in, not API key
ChatGPT Windows desktop app: 26.915.31029
OS: Windows 11 Pro 25H2
OS build: 26200.9457
Windows Feature Experience Pack: 1000.26100.360.0

Same account, different surfaces

Web → Work: GPT-6 Astra is visible and selectable
Windows Desktop → Work: GPT-6 Astra is missing
Windows Desktop → Codex: GPT-6 Astra is missing
Windows Desktop → Settings → Usage: Plus subscription and Work/Codex usage limits are recognized correctly; usage is not exhausted

The Windows model pickers show only:

GPT-5.6 Sol
GPT-5.6 Terra
GPT-5.6 Luna
GPT-5.5

Troubleshooting already completed

Manually checked for updates multiple times
Updated to the latest desktop version available to me
Fully quit ChatGPT and terminated ChatGPT/Codex background processes
Restarted the app
Signed out and back into the same ChatGPT account
Reset the Windows app
Reinstalled the Windows app
Tested brand-new Work and Codex conversations

The issue persists.

In-app feedback issue

OpenAI Support asked me to submit an in-app report from the affected Windows desktop app and provide the returned session ID. The feedback flow did not return a session ID; instead it showed:

Feedback upload unconfirmed. We couldn't confirm whether your feedback was received. It may have been sent, and resubmitting may result in a duplicate submission.

Support then directed me to report the issue on this repository.

I have not yet checked whether a stale CODEX_CLI_PATH override or an older effective app-server/runtime is involved. Given the reports above, I can provide those read-only diagnostics next if useful.

This reproduces the same core symptom as this issue, with the additional detail that Astra is missing from both Desktop Work and Desktop Codex while remaining available on Web Work for the same Plus account, on desktop version 26.915.31029.

Confirmed fixed on my Windows machine. This was a stale CODEX_CLI_PATH override causing the current ChatGPT Desktop shell to launch an old Codex runtime.

Environment

ChatGPT plan: Plus
Authentication: ChatGPT account sign-in, not API key
ChatGPT Windows desktop app: 26.915.31029
OS: Windows 11 Pro 25H2
OS build: 26200.9457

Broken state

Before the fix, the user/process environment variable was:

CODEX_CLI_PATH=C:\Users\1\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

Process inspection showed that ChatGPT Desktop was actually launching:

C:\Users\1\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

and the effective runtime version was:

codex-cli 0.149.1

At that point:

Web → Work: GPT-6 Astra was available
Windows Desktop → Work: GPT-6 Astra was missing
Windows Desktop → Codex: GPT-6 Astra was missing
Desktop itself reported that it was fully up to date

Fix

I removed the stale user-level override:

[Environment]::SetEnvironmentVariable(
    "CODEX_CLI_PATH",
    $null,
    "User"
)

Remove-Item Env:CODEX_CLI_PATH -ErrorAction SilentlyContinue

I then restarted Windows so Explorer / pinned shortcuts inherited the clean environment.

Working state after reboot

After launching ChatGPT Desktop normally, process inspection showed that Desktop switched to its bundled/relocated runtime:

C:\Users\1\AppData\Local\OpenAI\Codex\bin\cdef5aaf3e41ab53\codex.exe

with:

codex-cli 0.155.0-alpha.9

Immediately after that:

ChatGPT Desktop showed the GPT-6 Astra introduction dialog
GPT-6 Astra appeared in the Windows Desktop Work model picker
GPT-6 Astra appeared in the Windows Desktop Codex model picker
Astra is now selectable and working normally

No .codex deletion, session deletion, cache wipe, or further reinstall was required.

Conclusion

This is a reproducible upgrade/migration failure mode:

Current Desktop shell
+ stale persistent CODEX_CLI_PATH
-> Desktop silently launches old codex-cli 0.149.1
-> GPT-6 Astra hidden

Remove stale CODEX_CLI_PATH
+ reboot/relaunch
-> Desktop launches bundled runtime 0.155.0-alpha.9
-> GPT-6 Astra appears immediately

This strongly supports adding a startup/updater check that detects when CODEX_CLI_PATH points to an older/incompatible runtime, warns the user, and falls back to the bundled runtime instead of silently hiding newer models.

Thanks to the reports in this thread—the CODEX_CLI_PATH diagnostic led directly to the fix.

Additional reproduction on ChatGPT Plus / Windows Desktop, with stronger diagnostics showing this is a Desktop Work picker/session-routing issue rather than Astra entitlement or backend availability.

Environment:

ChatGPT Windows Desktop: 26.915.31945
Codex CLI/runtime: 0.155.0-alpha.9.2
Subscription: ChatGPT Plus
Authentication: ChatGPT login
Platform: Windows

Account behavior:

GPT-6 Astra is available in ChatGPT Work on Web.
GPT-6 Astra is available in ChatGPT Work on Mobile.
GPT-6 Astra is missing from the Windows Desktop Work model picker.

Windows picker currently shows only:

GPT-5.6 Sol
GPT-5.6 Terra
GPT-5.6 Luna
GPT-5.5

Diagnostics:

Both the bundled and live model catalogs contain Astra and mark it visible:

slug          display_name   visibility   priority
gpt-6-astra   GPT-6-Astra    list         1

Direct invocation succeeds when authenticated with ChatGPT:

model: gpt-6-astra
provider: openai
ASTRA_OK

A stale user-level CODEX_API_KEY was discovered during troubleshooting and removed. After removal:

codex login status reports Logged in using ChatGPT
direct -m gpt-6-astra invocation succeeds
all CODEX_API_KEY scopes are unset

config.toml can be set to:

service_tier = "default"
model = "gpt-6-astra"
model_reasoning_effort = "xhigh"
model_provider = "openai"
forced_login_method = "chatgpt"

Restarting the Desktop app does not overwrite this config by itself.

However, the Windows Desktop Work GUI still displays GPT-5.6 Sol, and the actual Work session metadata confirms the GUI-created session really runs:

"model":"gpt-5.6-sol"
"effort":"medium"

So this is not only a display-label mismatch; the Desktop GUI session is actually routed to Sol.

Selecting Default in the Desktop model picker rewrites the user config from Astra/xhigh back to:

model = "gpt-5.6-sol"
model_reasoning_effort = "medium"

Troubleshooting already performed:

Updated Desktop app to latest available build
Windows App reset
Signed out/in
Fully terminated ChatGPT/Codex processes
Reset/reinstalled Work workspace dependencies
Runtime updated from 0.151.0-alpha.7.2 to 0.155.0-alpha.9.2
Confirmed Astra exists in bundled + live catalogs
Confirmed visibility = list
Confirmed direct Astra inference works with ChatGPT auth

Conclusion:
The account entitlement and Astra backend access are working. The current Windows Desktop Work picker/session selection path appears to filter out Astra and route GUI sessions to GPT-5.6 Sol despite gpt-6-astra being present in the live catalog with visibility=list.

This also reproduces on Plus, not only Pro.

@king-zxy

@king-zxy
try updating. This should appear
https://github.com/openai/codex/releases

the hell anthropic doing? are they even trying to keep their user base? all i see is people complain over anthropic on Twitter - even the people negative over Codex are still very positive over what they were able to use

@king-zxy try updating. This should appear https://github.com/openai/codex/releases

Thank-you, fixed it for me.

Follow-up: I reproduced the same pattern again with the next GPT-6 model rollout.

Environment:

Windows
ChatGPT Plus
ChatGPT Desktop
Codex CLI was still at 0.153.4

Observed behavior:

GPT-6 Sol and GPT-6 Luna were already available on the web side for the account.
They were missing from the Desktop model picker.
Restarting the Desktop app alone did not resolve it.
After updating Codex CLI and then fully restarting ChatGPT Desktop, both GPT-6 Sol and GPT-6 Luna appeared immediately.

This is the second time I have seen the same dependency pattern:

Earlier, updating Codex CLI from 0.149.1 to 0.153.4 made GPT-6 Astra appear in Desktop Work.
Now, updating the CLI again after GPT-6 Sol/Luna launched made Sol and Luna appear as well.

This suggests that, at least on this Windows setup, the Desktop model picker is effectively sensitive to the local Codex CLI/runtime version even when ChatGPT Desktop itself reports that it is fully up to date.

The current Codex release notes also mention model-picker support for GPT-6 Sol and GPT-6 Luna, which is consistent with what I observed.

Suggested troubleshooting guidance for Windows users:

If a newly launched model is visible on the web but missing in Desktop, check codex --version.
Update Codex CLI.
Fully quit and relaunch ChatGPT Desktop.

This may help distinguish a local runtime/catalog version mismatch from a staged account rollout issue.

I can reproduce this on Windows, and the desktop app appears to be using an outdated bundled Codex CLI even though the standalone npm CLI is current.

In-app feedback/session ID: 01a0ce67-90d3-7f40-8050-2959cd666869
Codex Desktop: 26.917.62051 (build 10789, prod)
Standalone Codex CLI: 0.156.1
Desktop process CODEX_CLI_PATH: C:\Users\liu\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
That bundled executable reports: codex-cli 0.150.1
User-level and machine-level CODEX_CLI_PATH are not set, so this is not a stale user/system environment override.
The same signed-in account can successfully run both gpt-6-astra and gpt-6-sol through standalone CLI 0.156.1.
models_cache.json was refreshed by CLI 0.156.1 and contains gpt-6-astra, gpt-6-sol, and gpt-6-luna, but the Windows Desktop model picker still only shows the older GPT-5.6-era catalog after a full quit/relaunch.
There is no model_catalog_json override; the user config only selects model = "gpt-6-sol".

This looks like a Desktop packaging/update problem: the current desktop shell is still launching its bundled CLI 0.150.1, while model-picker support for the newer models is present in CLI 0.156.1.

I can confirm that I have experienced a very similar model-visibility issue on Codex Desktop for Windows, and in my case this behavior actually started much earlier, around the initial GPT-6 Astra rollout.

When Astra first became available, I could already access it through other Codex surfaces, including VS Code Codex / CLI, while Astra was missing from the Windows Codex Desktop model picker. I did not report the issue at the time, so there is unfortunately no issue report from me dating back to the initial Astra rollout.

The important point is that, from my experience, this class of model-visibility problem appears to predate the recent GPT-6 Sol/Luna rollout. The newer reports about Sol/Luna being available to the same account in CLI or other surfaces but missing from Windows Desktop look very similar to what I previously experienced with Astra.

My environment is Windows 11, and the comparison is particularly useful because the affected Desktop app and the working VS Code Codex / CLI are on the same machine and use the same ChatGPT account.

Observed pattern:

Same ChatGPT account
Same Windows PC
Model available in VS Code Codex / CLI
Model missing from Codex Desktop model picker
The issue was already occurring during the original Astra rollout
I did not submit a bug report when I first encountered it

This makes me suspect that this may not be purely an account entitlement issue, but could involve model catalog / entitlement synchronization, caching, or another Desktop-specific state issue.

I am adding this information mainly to provide an earlier data point: similar model visibility inconsistencies were already happening on my Windows Codex Desktop installation when Astra was first released.

Update on my ChatGPT Plus / Windows reproduction: the issue is now resolved on my machine as of 2026-09-28.

GPT-6 Astra now appears normally in the Windows Desktop Work model picker, and I can select/use it from the GUI.

Previously, this same installation/account had:

Astra available on Web and Mobile
Astra present in bundled + live catalogs with visibility=list
direct CLI invocation working
but Astra missing from the Windows Desktop picker and GUI sessions falling back to GPT-5.6 Sol

The Windows Desktop picker is now showing GPT-6 Astra normally, so my specific reproduction can be considered resolved.

I am leaving the parent issue open because I am not the original reporter/maintainer and other users may still be affected.

[Windows Desktop] GPT-6 Astra missing from model picker for eligible ChatGPT Pro account #42853

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

optimikelabs commented on Sep 4, 2026

glook9001 commented on Sep 4, 2026

justinleahy commented on Sep 4, 2026

willfenton commented on Sep 5, 2026

mdbro commented on Sep 5, 2026

hra42 commented on Sep 5, 2026

willfenton commented on Sep 5, 2026

nmbgeek commented on Sep 5, 2026

glook9001 commented on Sep 5, 2026

vmffl1213-alt commented on Sep 6, 2026

l0westbob commented on Sep 6, 2026

codex exec --ephemeral --skip-git-repo-check --ignore-user-config --model gpt-6-astra --sandbox read-only "Respond with exactly ASTRA_OK and do not call tools." OpenAI Codex v0.145.0

workdir: redacted model: gpt-6-astra provider: openai approval: never sandbox: read-only reasoning effort: none reasoning summaries: none session id: 01a07522-48ee-7dd1-bf39-fed756a0345e

/Applications/ChatGPT.app/Contents/Resources/codex exec \ --ephemeral --skip-git-repo-check --ignore-user-config --model gpt-6-astra --sandbox read-only "Respond with exactly ASTRA_OK and do not call tools." OpenAI Codex v0.153.4

workdir: redacted model: gpt-6-astra provider: openai approval: never sandbox: read-only reasoning effort: none reasoning summaries: none session id: 01a0752b-01da-7711-8441-e2431203c3ce

ButtercatT commented on Sep 6, 2026

Environment

Root cause

Resolution

Suggested diagnostic / UX improvement

11 remaining items

kktbur commented on Sep 13, 2026

yanglongyang commented on Sep 14, 2026

Before the fix

What changed

Safe recovery path that worked

What this suggests

amibars commented on Sep 15, 2026

amibars commented on Sep 17, 2026

A/B result

Suggested product fix

amibars commented on Sep 17, 2026

Fully reproduced A/B

Broken state

Reversible A/B test

Permanent recovery performed

Standalone CLI is independent and healthy

What I think the Desktop updater/startup migration should do

Why this matters for the update experience

StevenVinel commented on Sep 18, 2026

Environment

Same account, different surfaces

Troubleshooting already completed

In-app feedback issue

StevenVinel commented on Sep 18, 2026

Environment

Broken state

Fix

Working state after reboot

Conclusion

king-zxy commented on Sep 19, 2026

glook9001 commented on Sep 20, 2026

glook9001 commented on Sep 20, 2026

spammenotinoz commented on Sep 20, 2026

z030813z-blip commented on Sep 23, 2026

Liu129779 commented on Sep 24, 2026

chopper10elf-lan commented on Sep 25, 2026

king-zxy commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

codex exec --ephemeral --skip-git-repo-check --ignore-user-config --model gpt-6-astra --sandbox read-only "Respond with exactly ASTRA_OK and do not call tools."
OpenAI Codex v0.145.0

workdir: redacted
model: gpt-6-astra
provider: openai
approval: never
sandbox: read-only
reasoning effort: none
reasoning summaries: none
session id: 01a07522-48ee-7dd1-bf39-fed756a0345e

/Applications/ChatGPT.app/Contents/Resources/codex exec \
--ephemeral
--skip-git-repo-check
--ignore-user-config
--model gpt-6-astra
--sandbox read-only
"Respond with exactly ASTRA_OK and do not call tools."
OpenAI Codex v0.153.4

workdir: redacted
model: gpt-6-astra
provider: openai
approval: never
sandbox: read-only
reasoning effort: none
reasoning summaries: none
session id: 01a0752b-01da-7711-8441-e2431203c3ce