macOS: `codex app` ignores installed ChatGPT.app and creates duplicate Codex.app

Resolved 💬 6 comments Opened Jul 9, 2026 by DCjanus Closed Jul 17, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.144.1

What subscription do you have?

ChatGPT Pro (20x)

Which model were you using?

Not applicable (no model invocation)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Ghostty 1.3.2-main-+688750903 (no multiplexer)

Codex doctor report

{
  "schemaVersion": 1,
  "overallStatus": "fail",
  "codexVersion": "0.144.1",
  "relevantChecks": {
    "auth.credentials": {
      "status": "ok",
      "authMode": "chatgpt"
    },
    "installation": {
      "status": "ok",
      "currentExecutable": "~/.local/bin/codex",
      "pathEntries": [
        "~/.local/bin/codex",
        "/Applications/ChatGPT.app/Contents/Resources/codex"
      ]
    },
    "runtime.provenance": {
      "status": "ok",
      "platform": "macos-aarch64",
      "version": "0.144.1"
    },
    "updates.status": {
      "status": "ok",
      "latestVersion": "0.144.1",
      "versionStatus": "current"
    }
  },
  "note": "Sanitized relevant excerpt. The overall failure is only TERM=dumb because doctor was captured non-interactively; it is unrelated to this bug."
}

What issue are you seeing?

After the Codex desktop app was renamed to ChatGPT.app, codex app . no longer detects the installed desktop app.

With /Applications/ChatGPT.app already installed and no /Applications/Codex.app, the command reports:

Codex Desktop not found; downloading installer...

It downloads the current ChatGPT installer, mounts it as ChatGPT Installer, but copies the contained app bundle to /Applications/Codex.app.

This leaves both ChatGPT.app and Codex.app installed. Both report the same bundle identifier and version, and their main executable, app.asar, and bundled codex executable have identical SHA-256 hashes. This wastes about 1.4 GB and may leave macOS with two paths for the same bundle identifier.

What steps can reproduce the bug?

  1. Install the current desktop app as /Applications/ChatGPT.app.
  2. Ensure /Applications/Codex.app does not exist.
  3. Run:

``console
codex app .
``

  1. Observe:

``text
Codex Desktop not found; downloading installer...
Downloading installer...
Mounting Codex Desktop installer...
Installer mounted at /Volumes/ChatGPT Installer.
Installing Codex Desktop into /Applications...
Launching Codex Desktop from /Applications/Codex.app...
``

  1. Check /Applications. Both ChatGPT.app and Codex.app now exist.

This reproduced consistently from the stated precondition on Codex CLI 0.144.1.

What is the expected behavior?

codex app . should detect and launch the existing /Applications/ChatGPT.app, either by its current path or its bundle identifier (com.openai.codex).

It should not download or install another copy when the unified ChatGPT/Codex desktop app is already installed.

Additional information

Both resulting bundles report:

CFBundleDisplayName: ChatGPT
CFBundleName: ChatGPT
CFBundleIdentifier: com.openai.codex
CFBundleShortVersionString: 26.707.31123
CFBundleVersion: 5042
CFBundleExecutable: ChatGPT

Matching SHA-256 hashes:

Main executable: 451ef0490b2b69fa67cb56e2b572082853b306fad0212e7faf94a8ad20ec2c84
app.asar: c5a6dd83cb104957b6eb3c055273159b61bfa003b81629fa7458fbdeaffc7db5
Bundled codex: e32fa26689d3f4c30c04aad6b49c8b9705d40ee2f13dc7516276e9023c5f815e

The current launcher only checks /Applications/Codex.app and ~/Applications/Codex.app:
https://github.com/openai/codex/blob/cbdee7976b3717e3e0b7fbe83e2aa2843f1aa500/codex-rs/cli/src/desktop_app/mac.rs#L66-L78

The installer also hard-codes the destination name Codex.app:
https://github.com/openai/codex/blob/cbdee7976b3717e3e0b7fbe83e2aa2843f1aa500/codex-rs/cli/src/desktop_app/mac.rs#L148-L167

Related but distinct: #31866 reports the desktop self-update/migration behavior, not this codex app duplicate-install path.

View original on GitHub ↗

6 Comments

ronething · 11 days ago

I've also encountered this issue.

maximtop · 10 days ago

I have same problem on macOS. codex-cli 0.144.1 resolves from my fnm Node installation; /Applications/ChatGPT.app version 26.707.31428 (build 5059) is installed with bundle identifier com.openai.codex, while /Applications/Codex.app is absent.

Running codex app . reports Codex Desktop not found; downloading installer... and starts a 535 MB download. I interrupted it to avoid installing a duplicate. As a temporary workaround, open -a /Applications/ChatGPT.app . opens the repository in the unified app.

erikhuizinga · 10 days ago

I suspect the copy that codex app would install causes macOS to show a potential malware alert dialog aboud the bundled ripgrep (rg) executable. I reported this here with a workaround: https://github.com/BurntSushi/ripgrep/issues/3469. But the issue is, I suspect, on the codex cli side.

xdotli · 8 days ago

+1

junbuilds96 · 6 days ago

I verified that this still reproduces against current main. The macOS launcher only checks the standard Applications directories for the literal Codex.app name, while the unified app is installed as ChatGPT.app and still uses CFBundleIdentifier = com.openai.codex.

I would propose a focused macOS-only fix:

  • consider both ChatGPT.app and the legacy Codex.app under /Applications and ~/Applications;
  • read each candidate's Contents/Info.plist with the system plutil and only accept com.openai.codex;
  • keep launching the verified absolute path with the existing codex://threads/new?path=... deep link;
  • preserve the existing download/install fallback and leave Windows and installer naming/migration out of scope.

The bundle ID check is important because some machines may still have the classic ChatGPT.app with bundle ID com.openai.chat; adding the new filename alone could launch the wrong product.

I would add regression coverage for discovering a unified ChatGPT.app, plus compatibility coverage that skips a com.openai.chat candidate and falls back to a valid legacy Codex.app.

Per docs/contributing.md, external PRs require an explicit invitation. If this approach aligns with the intended fix, would a maintainer be willing to invite a focused PR for #31944?

etraut-openai contributor · 4 days ago

Thanks for the bug report. I'm working on a fix.