codex app . opens Codex Desktop without the current workspace on macOS

Resolved 💬 3 comments Opened Jun 2, 2026 by tsonubin Closed Jun 2, 2026

💡 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.136.0

What subscription do you have?

ChatGPT subscription; the issue does not appear to be plan-specific.

Which model were you using?

N/A

What platform is your computer?

Darwin 25.5.0 arm64 arm

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

Warp

Codex doctor report

codex doctor --json reported overallStatus: "ok" with the update configuration locally consistent.

What issue are you seeing?

On macOS, codex app . opens Codex Desktop, but the new thread is not opened with the current directory as its workspace. The app lands on the projectless "What should we work on?" screen instead.

The deep link itself appears valid. Opening the same encoded workspace URL by bundle id works:

open -b com.openai.codex 'codex://threads/new?path=%2Fpath%2Fto%2Fworkspace'

The failing path in the CLI currently launches the URL using open -a <Codex.app path> <codex://...>. In local testing, targeting the bundle id with open -b com.openai.codex <codex://...> routes the deep link correctly and Codex Desktop opens the intended workspace.

What steps can reproduce the bug?

Install Codex CLI and Codex Desktop on macOS.
From a local repository, run:

``sh codex app .``

Observe that Codex Desktop opens without the current directory selected as the workspace.
Open the equivalent deep link manually via bundle id:

``sh open -b com.openai.codex 'codex://threads/new?path=%2Fpath%2Fto%2Fworkspace'``

Observe that Codex Desktop opens the intended workspace.

What is the expected behavior?

codex app . should open Codex Desktop with the current directory selected as the workspace, matching the documented codex://threads/new?path=<absolute-dir> deep-link behavior.

Additional information

I have a small patch prepared that changes the macOS desktop launch path from open -a <app path> <url> to open -b com.openai.codex <url> and adds a regression test for the open arguments. This keeps app discovery/install behavior intact while routing the workspace deep link through Launch Services by the registered bundle id.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

#25166

Powered by Codex Action

tsonubin · 2 months ago

I reviewed the duplicate candidate and related issues:

#25166 is related but not the same surface. It was about open -a Codex <path> and was closed after the documented deep link was identified.
#25333 looks like the closest match because it covers the documented codex app <path> entry point. It has a maintainer comment saying it will be fixed in the next release.

This report may still be useful because the reproduction here is with codex-cli 0.136.0, and the behavior is narrower than just "app does not open": Codex Desktop launches, but the workspace from codex app . is not applied.

The deep link itself appears to work when opened through the bundle id:

open -b com.openai.codex 'codex://threads/new?path=%2Fpath%2Fto%2Fworkspace'

That suggests the macOS CLI handoff can be fixed by launching the generated codex://threads/new?path=... URL with open -b com.openai.codex rather than open -a <Codex.app path> <url>.

tsonubin · 2 months ago

Close issue due to dupilcate. #25863 and already merged into main. Waiting for next release.