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

Open 💬 2 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 ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗