Codex Desktop v26.527 no longer opens workspace from `open -a Codex <path>` on macOS

Resolved 💬 5 comments Opened May 29, 2026 by osamu2001 Closed May 31, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Starting the morning of 2026-05-30 JST, launching Codex Desktop with a workspace path from macOS open no longer works:

open -a Codex "$PWD"

This used to open Codex.app with the provided working directory selected as the workspace/project. After today's Codex.app auto-update, the same command no longer opens the requested workspace.

Environment

Hardware/arch: Apple Silicon (arm64)
macOS: 26.4 (25E246)
App path: /Applications/Codex.app
Bundle ID: com.openai.codex
Observed app version after update:
CFBundleShortVersionString: 26.527.31326
CFBundleVersion: 3390
Spotlight kMDItemVersion: 26.527.31326
App content change time: 2026-05-29 22:29:45 +0000 (2026-05-30 07:29:45 JST)
Earlier during the same morning, the installed app was observed as:
26.527.30818 / 3370
content change time 2026-05-29 21:40:18 +0000 (2026-05-30 06:40:18 JST)

Code signature metadata from the current app:

Executable=/Applications/Codex.app/Contents/MacOS/Codex
Identifier=com.openai.codex
Format=app bundle with Mach-O thin (arm64)
TeamIdentifier=2DC432GLL2
Runtime Version=26.5.0

Reproduction

From any local repository/workspace directory:

cd /path/to/workspace
open -a Codex "$PWD"

Expected behavior

Codex Desktop opens/focuses and uses the supplied path as the workspace/project, matching the behavior before the 2026-05-30 JST app update.

Actual behavior

The command no longer opens the requested workspace in Codex Desktop. This appears to be a regression in the macOS app path-launch behavior introduced by the 26.527 app update train.

Notes

I searched existing open issues for open -a Codex, Codex.app, 26.527.30818, and workspace launch regressions. I found related macOS LaunchServices issue #24072, but this report is specifically about the open -a Codex <path> workspace argument no longer working after today's app update.

View original on GitHub ↗

5 Comments

osamu2001 · 3 months ago

Update after installing the latest app build available this morning: the regression is still present on 26.527.31326 / 3390.

Current app metadata:

kMDItemCFBundleIdentifier  = "com.openai.codex"
kMDItemFSContentChangeDate = 2026-05-29 22:29:45 +0000
kMDItemVersion             = "26.527.31326"
CFBundleShortVersionString = 26.527.31326
CFBundleVersion            = 3390

I also tested a fresh temporary workspace path:

tmpdir=$(mktemp -d /tmp/codex-open-test.XXXXXX)
open -a Codex "$tmpdir"

The open command exits successfully (0), and LaunchServices sees Codex.app as a foreground running app:

bundleID="com.openai.codex"
bundle path="/Applications/Codex.app"
executable path="/Applications/Codex.app/Contents/MacOS/Codex"
pid = <pid> type="Foreground" flavor=3 Version="3390" fileType="APPL" Arch=ARM64

So this is not the same failure mode as #24072 where LaunchServices marks the app as stopped. The app launches/focuses, but the workspace path argument from open -a Codex <path> is still not honored after updating.

github-actions[bot] contributor · 3 months ago

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

#24072

Powered by Codex Action

rahulxsomething · 2 months ago

I hit the same codex app regression. here is the workaround I am using:

Add this to ~/.zshrc or ~/.bashrc:

codex-open() {
  dir="${1:-$PWD}"
  dir="$(cd "$dir" && pwd -P)" || return 1
  encoded="$(dir="$dir" /usr/bin/osascript -l JavaScript -e 'ObjC.import("stdlib"); encodeURIComponent($.getenv("dir"))')" || return 1
  /usr/bin/open "codex://new?path=$encoded"
}

Then use:

codex-open ~/path/to/project

osamu2001 · 2 months ago

I do not think #24072 is a duplicate. In #24072, the issue appears to be that LaunchServices marks the app as stopped / no longer open. In this issue, Codex does launch and focus correctly, but the workspace path argument is not honored.

This looks closely related to #25333. The entry points are different — open -a Codex "$PWD" here, and codex app <path> in #25333 — but both fail to open/focus the requested workspace on 26.527.31326 / 3390. So I suspect these may be two surfaces of the same workspace-path launch regression, rather than a LaunchServices-only issue.

@rahulxsomething Thank you for the workaround you suggested. It works well for me.

osamu2001 · 2 months ago

Following @rahulxsomething's workaround, I looked into this a bit more and noticed that Codex.app has a documented deep-link entry point for this use case:

codex://threads/new?path=<absolute-path>

So for this issue, I no longer think we need to rely on the undocumented open -a Codex "$PWD" behavior.

Separately, #25333 should still be fixed because codex app [PATH] is documented in the CLI help as Workspace path to open in Codex Desktop [default: .].

But this issue was specifically about open -a Codex "$PWD". Since the documented deep link covers my use case, I think this issue is fine to close.

Thanks again @rahulxsomething for pointing me in the right direction.