`codex app` fails to detect the unified ChatGPT.app and downloads the installer (CLI still looks for Codex.app)

Open 💬 4 comments Opened Jul 12, 2026 by solrevdev
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.144.1 (latest release at time of filing, installed via Homebrew cask codex)

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS, Apple Silicon)

What happened?

Since the July 9 merge of the Codex desktop app into the unified ChatGPT app (changelog: "Codex is now part of the ChatGPT desktop app on macOS and Windows"), codex app . no longer detects the installed desktop app and instead tries to download the installer:

$ codex app .
Codex Desktop not found; downloading installer...
Downloading installer...

This happens even though the unified app is installed and up to date:

  • /Applications/ChatGPT.app — bundle ID com.openai.codex, version 26.707.51957 (this is the renamed Codex app)
  • /Applications/ChatGPT Classic.app — bundle ID com.openai.chat (the old chat app)

Root cause

The CLI binary hard-codes the old app name. Strings in the 0.144.1 binary show it checks Applications directories for the literal Codex.app and falls back to downloading https://persistent.oaistatic.com/codex-app-prod/Codex.dmg:

failed to install Codex.app to any applications directory
Codex Desktop not found; downloading installer...

Since the migration renamed the bundle to ChatGPT.app (keeping bundle ID com.openai.codex), the name-based lookup can never succeed on a migrated machine. Detection by bundle ID (com.openai.codex) instead of bundle name would fix this.

Expected behavior

codex app . opens the current directory as a workspace in the installed unified ChatGPT app, as documented:

If the fix will take a while, a docs note on those pages would help — right now users who manage the app via Homebrew (or any means other than the CLI's own installer) get an unwanted second install path.

Workaround

open -a ChatGPT . works, because ChatGPT.app declares public.folder in its document types.

Related

Possibly related migration fallout: #31866, #32022

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #31944
  • #32464

Powered by Codex Action

xdotli · 1 month ago

+1

spqw · 1 month ago

+1

q43607238 · 1 month ago

Confirmed on the latest stable CLI with a newer unified desktop app.

Environment

  • Codex CLI: codex-cli 0.144.5 (current npm latest)
  • macOS: 26.5.2 (build 25F84), arm64
  • Desktop app: 26.715.21425
  • Installed path: /Applications/ChatGPT.app

Reproduction

From any local directory:

$ codex app .
Codex Desktop not found; downloading installer...
Downloading installer...

The download shown by the CLI is about 589 MB, even though the unified app is already installed and running.

Additional diagnostics

The installed app's Info.plist contains:

CFBundleIdentifier = com.openai.codex
CFBundleDisplayName = ChatGPT
CFBundleName = ChatGPT
CFBundleAlternateNames = [Codex]
CFBundleShortVersionString = 26.715.21425
CFBundleURLSchemes = [codex]

Spotlight also resolves the bundle at /Applications/ChatGPT.app. This further suggests that app discovery is still relying on the old filesystem name (Codex.app) instead of the bundle ID or LaunchServices.

The issue is reproducible after the CLI was updated to 0.144.5; it is not fixed in the current stable release.