[Windows] `codex app` falsely reports Desktop missing when StartApps entry is named ChatGPT
What version of Codex CLI is running?
codex-cli 0.144.0-alpha.4
What version of Codex Desktop is installed?
OpenAI.Codex 26.707.3748.0 from the Microsoft Store / AppX package.
Platform
- Microsoft Windows 11 Pro
- Version
10.0.26200, build26200 - 64-bit
What issue are you seeing?
On Windows, codex app <workspace> reports that Codex Desktop is not installed and opens the installer even though the current OpenAI.Codex AppX package is installed, healthy, running, and its codex:// protocol is registered.
Observed output:
Codex Desktop not found; opening Windows installer...
After installing Codex Desktop, open workspace C:\work\repo.
The false negative comes from the current installation check in codex-rs/cli/src/desktop_app/windows.rs:
Get-StartApps -Name 'Codex' | Select-Object -First 1 -ExpandProperty AppID
On the affected installation, the package's Start entry is named ChatGPT, not Codex:
PS> Get-StartApps -Name 'Codex'
# no output
PS> Get-StartApps | Where-Object { $_.AppID -like 'OpenAI.Codex_*!App' }
Name AppID
---- -----
ChatGPT OpenAI.Codex_2p2nqsd0c76g0!App
AppX itself is healthy:
Name: OpenAI.Codex
Version: 26.707.3748.0
Status: Ok
AppID: OpenAI.Codex_2p2nqsd0c76g0!App
The package manifest also registers the codex protocol, and protocol activation works.
Steps to reproduce
- Install the current Microsoft Store / AppX Codex Desktop package on a machine where its Start entry is displayed as
ChatGPT. - Install or use the bundled/standalone Windows Codex CLI.
- Run:
``powershell``
codex app C:\work\repo
- Observe that the CLI opens the installer instead of the installed Desktop app.
Expected behavior
The CLI should detect the installed OpenAI.Codex package independently of its localized or packaged display name, then open the existing codex://threads/new?path=... protocol URL.
Suggested repair
Detect the stable package/application identity rather than querying the mutable display name. For example:
Get-StartApps |
Where-Object { $_.AppID -like 'OpenAI.Codex_*!App' } |
Select-Object -First 1 -ExpandProperty AppID
Alternatively, use Get-AppxPackage -Name OpenAI.Codex and rely on protocol activation for the final launch check.
A focused regression test should cover this case:
- display name is
ChatGPT - AppID is
OpenAI.Codex_...!App - installation check succeeds
- launcher uses the registered
codex://protocol
Additional evidence
The executable used from LocalAppData is byte-for-byte identical to the active AppX bundled codex.exe; there is no stale npm Codex installation. Direct execution from C:\Program Files\WindowsApps is denied by normal package ACLs and should not be used as a workaround.
Issue #28667 is related but distinct: it concerns the TUI /app path directly executing a packaged WindowsApps executable. This report concerns the codex app <workspace> preflight returning a false not installed result because it searches by display name.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗