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.