›_ Codex Issues
Codex Issues / #32464

[Windows] `codex app` falsely reports Desktop missing when StartApps entry is named ChatGPT

Open 💬 4 comments Opened Jul 11, 2026 by refusedzero

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, build 26200
  • 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

  1. Install the current Microsoft Store / AppX Codex Desktop package on a machine where its Start entry is displayed as ChatGPT.
  2. Install or use the bundled/standalone Windows Codex CLI.
  3. Run:

``powershell
codex app C:\work\repo
``

  1. 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.

View original on GitHub ↗

4 Comments

starriet9 · 1 month ago

I reproduced this independently on Windows 10 Pro with the same current Desktop package and a standalone Codex CLI installation.

Codex CLI: codex-cli 0.144.1
Desktop package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
Package status: Ok
Start app name: ChatGPT
Start app ID: OpenAI.Codex_2p2nqsd0c76g0!App

As in this report, Get-StartApps -Name 'Codex' returns no result even though the package is healthy and the registered codex:// protocol works. Running codex app <workspace> follows the installer path because the current preflight is tied to that display name.

I prepared a focused candidate fix on current main (9e552e9d1, checked on 2026-07-12):

https://github.com/starriet9/codex/tree/fix/windows-app-package-detection

Current commit:

https://github.com/starriet9/codex/commit/0b45471acef5d9118360496e9adff602b56d69c4

The candidate replaces the Start-menu display-name query with an exact AppX package identity check:

Get-AppxPackage -Name 'OpenAI.Codex' -ErrorAction SilentlyContinue |
  Where-Object { $_.PublisherId -eq '2p2nqsd0c76g0' } |
  Select-Object -First 1 -ExpandProperty PackageFullName

This makes detection independent of the mutable/localized Codex versus ChatGPT display name and also requires the official OpenAI publisher ID. The existing codex://threads/new?... protocol launch remains unchanged.

Validation on Windows:

just test -p codex-cli install_check_uses_package_identity_instead_of_display_name
just fix -p codex-cli
cargo fmt --all -- --check
git diff --check origin/main...HEAD

The targeted regression test passes on current main. The Clippy fix pass, rustfmt check, and diff check also passed for the same one-commit candidate. The exact package-identity query found the installed package above even though its Start app display name is ChatGPT.

An earlier full codex-cli run of the same candidate passed 298 of 299 tests. The remaining unrelated doctor::thread_inventory test failed identically from unmodified main in the same environment.

This Windows identity check follows the same package-name and publisher-ID direction proposed in the closed maintainer PR #28253, while keeping this candidate limited to the reported codex app false negative. If maintainers prefer the focused fix, the branch is ready for a PR invitation.

postigodev · 1 month ago

I can independently reproduce this on the latest stable Codex CLI.

Environment

  • Codex CLI: codex-cli 0.144.4
  • Codex Desktop package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
  • Windows: 10.0.26200.8655 (Windows 11 Core, x64)
  • CLI installation method: standalone Windows installer
  • CLI executable: C:\Users\akuma\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

Observed behavior

Running:

codex app .

produces:

Codex Desktop not found; opening Windows installer...
After installing Codex Desktop, open workspace C:\Users\akuma\repos.

However, the AppX package is installed:

Get-AppxPackage *OpenAI* |
  Select-Object Name, PackageFullName, InstallLocation

Output:

Name         PackageFullName
----         ---------------
OpenAI.Codex OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0

The Start app entry is named ChatGPT rather than Codex:

Get-StartApps |
  Where-Object { $_.Name -match "Codex|ChatGPT" }

Output:

Name    AppID
----    -----
ChatGPT OpenAI.Codex_2p2nqsd0c76g0!App

Direct protocol activation successfully opens the requested workspace:

Start-Process -FilePath (
    'codex://threads/new?path=' +
    [uri]::EscapeDataString('C:\Users\akuma\repos\zurderio')
)

codex doctor reports:

17 ok · 1 idle · 1 notes · 0 warn · 0 fail

This confirms that the issue is still present in stable 0.144.4 and Desktop package 26.707.8479.0, while both the installed AppX package and the registered codex:// protocol are working correctly.

starriet9 · 15 days ago

This was fixed upstream by #33901 and shipped in the stable rust-v0.145.0 release. The merged implementation detects the stable Windows package AppID instead of depending on the Start-menu display name, so both Codex- and ChatGPT-branded Desktop builds are recognized.

I verified the release note and the current implementation. The focused local candidate discussed above is superseded by the merged upstream fix, and this issue can be closed as completed.

solrevdev · 13 days ago
This was fixed upstream by #33901 and shipped in the stable rust-v0.145.0 release. The merged implementation detects the stable Windows package AppID instead of depending on the Start-menu display name, so both Codex- and ChatGPT-branded Desktop builds are recognized. I verified the release note and the current implementation. The focused local candidate discussed above is superseded by the merged upstream fix, and this issue can be closed as completed.

Yes it works for me on macOS 🎉️

Thanks 🙏🏼️

▲ /tmp codex app .
Opening Desktop app at /Applications/ChatGPT.app...
Opening workspace /private/tmp...
▲ /tmp codex --version
codex-cli 0.147.0
▲ /tmp
ChatGPT
Powered by Codex & OWL
Version 26.810.41047