Windows CLI /app fails to open Desktop thread with Start-Process Access denied

Open 💬 6 comments Opened Jun 17, 2026 by starriet9

What version of Codex CLI is running?

codex-cli 0.140.0

Installed with the standalone Windows installer.

What subscription do you have?

ChatGPT Pro.

Which model were you using?

gpt-5.5.

What platform is your computer?

Output requested by the issue template:

Microsoft Windows NT 10.0.19045.0 x64

Windows edition: Windows 10 Pro 22H2.

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

Windows Terminal 1.24.11321.0

Shell: Windows PowerShell 5.1.19041.6456 (Desktop edition)

Codex doctor report

Summary of codex doctor --json with unnecessary path and session details omitted:

{
  "schemaVersion": 1,
  "codexVersion": "0.140.0",
  "overallStatus": "warning",
  "checks": {
    "installation": "ok",
    "runtime.provenance": "ok; standalone on windows-x86_64",
    "config.load": "ok",
    "auth.credentials": "ok",
    "state.paths": "ok",
    "network.provider_reachability": "ok",
    "network.websocket_reachability": "ok",
    "mcp.config": "ok",
    "terminal.env": "ok"
  },
  "notableWarning": "state.rollout_db_parity: rollout files and state DB thread inventory differ",
  "failedChecks": 0
}

The warning is about older rollout/session inventory parity and does not appear related to launching Codex Desktop from /app.

What issue are you seeing?

On Windows, the Codex CLI /app command fails to open the current CLI thread in Codex Desktop. The failure happens even though Codex Desktop is installed and registered.

Observed error with Codex CLI 0.140.0:

Failed to open this session in Codex Desktop: Start-Process : This command cannot be run due to the error: Access is denied.
At line:23 char:1
+ Start-Process -FilePath $exe -WorkingDirectory $appDir -ArgumentList  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand. Install or launch Codex Desktop and try again.

Codex Desktop registration on the same machine:

Codex Desktop package: OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0
Codex Desktop AppID: OpenAI.Codex_2p2nqsd0c76g0!App

The same failure was reproduced after confirming the Desktop package version above. Get-StartApps -Name 'Codex' returns the AppID above, so this does not appear to be a missing Desktop install.

I traced the failure to the Windows /app launcher path. It builds a PowerShell script that locates the AppX/MSIX install location and starts the packaged executable directly:

$installLocation = (Get-AppxPackage -Name OpenAI.Codex -ErrorAction SilentlyContinue).InstallLocation
$appDir = Join-Path $installLocation 'app'
$exe = Join-Path $appDir 'Codex.exe'
$app = Join-Path $appDir 'resources\app.asar'
Start-Process -FilePath $exe -WorkingDirectory $appDir -ArgumentList @('resources\app.asar', $url)

Starting the packaged Codex.exe directly from C:\Program Files\WindowsApps\... appears to be what triggers the Windows Access is denied error.

The same thread opens successfully in Codex Desktop when launched through the registered protocol handler:

Start-Process 'codex://threads/<thread_id>'

This confirms that Codex Desktop is installed, registered, and able to load the thread.

Related but not identical issues:

#28031 reports direct execution of a bundled WindowsApps codex.exe failing with access denied.
#28393 reports a generated apply_patch wrapper pointing at a WindowsApps codex.exe.

This issue is specifically about the CLI TUI /app handoff to Codex Desktop.

What steps can reproduce the bug?

Install Codex Desktop on Windows.
Install Codex CLI 0.140.0 with the standalone Windows installer.
Start or resume a Codex CLI thread.
Run /app from the CLI TUI.
Observe Failed to open this session in Codex Desktop with Start-Process ... Access is denied.

What is the expected behavior?

/app should open the current CLI thread in Codex Desktop.

On Windows, the TUI /app command should use the registered codex://threads/<thread_id> protocol handler instead of directly executing the AppX/MSIX package's Codex.exe from C:\Program Files\WindowsApps.

The CLI codex app command already opens a codex://threads/new?... URL through PowerShell Start-Process -FilePath $target, which avoids direct execution of the WindowsApps packaged executable.

Additional information

I prepared and tested a small candidate patch in a fork branch:

https://github.com/starriet9/codex/tree/fix/windows-app-open-thread-protocol

Summary of the candidate change:

Check that Codex Desktop is registered with Get-StartApps -Name 'Codex'.
Open the existing codex://threads/<thread_id> URL with Start-Process -FilePath $url.
Avoid constructing and directly launching C:\Program Files\WindowsApps\...\app\Codex.exe.
Add a regression test that verifies the Windows launcher uses the protocol handler and does not reference Get-AppxPackage, Codex.exe, or resources\app.asar.

Local verification on Windows:

cargo fmt --check
cargo test -p codex-tui windows_desktop_app_launch_uses_protocol_handler --lib

Both passed.

I also cherry-picked the patch onto the 0.140.0 tag and tested it manually from the TUI. With the patch applied, /app successfully opened the current thread in Codex Desktop.

I am not opening a PR yet because docs/contributing.md says external PRs are by invitation only. If this approach matches the intended Desktop handoff behavior, I can open a focused PR from the branch above.

View original on GitHub ↗

6 Comments

starriet9 · 1 month ago

Follow-up: I was able to validate the proposed /app launch change end-to-end on the affected Windows 10 machine.

Test setup:

git switch -c local-test/app-open-protocol-rust-v0.140.0 rust-v0.140.0
git cherry-pick 8bdf157
cargo build -p codex-cli --bin codex
.\target\debug\codex.exe --version
# codex-cli 0.140.0

Then from a separate PowerShell tab in the same workspace:

& "<local-codex-repo>\codex-rs\target\debug\codex.exe" resume --last

Inside the TUI, I entered:

/app

Result:

Codex Desktop launched successfully.
The same thread opened in Codex Desktop.
The previous Start-Process ... Access is denied failure did not occur.

So the protocol-handler based launch path fixes the originally reported /app handoff failure on this Windows 10 repro.

starriet9 · 1 month ago

Follow-up: this still reproduces after updating to Codex CLI 0.141.0 with the standalone Windows installer.

Current environment:

Codex CLI: codex-cli 0.141.0
Codex executable: C:\Users\<user>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
Codex Desktop package: OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0

Running /app from the resumed CLI thread still fails with the same launcher error:

Failed to open this session in Codex Desktop: Start-Process : This command cannot be run due to the error: Access is denied.
At line:23 char:1
+ Start-Process -FilePath $exe -WorkingDirectory $appDir -ArgumentList  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand. Install or launch Codex Desktop and try again.

So the issue is still present in the 0.141.0 stable CLI release. The failure mode is unchanged from the original report.

starriet9 · 27 days ago

Follow-up: this still reproduces after updating to the 0.142.0 stable CLI release.

Current environment:

Codex CLI: codex-cli 0.142.0
Codex Desktop package: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0

Running /app from the resumed CLI thread still fails with the same launcher error:

Failed to open this session in Codex Desktop: Start-Process : This command cannot be run due to the error: Access is denied.
At line:23 char:1
+ Start-Process -FilePath $exe -WorkingDirectory $appDir -ArgumentList  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand. Install or launch Codex Desktop and try again.

I also checked the rust-v0.142.0 source, and the Windows /app launcher still appears to use the WindowsApps Codex.exe / resources\app.asar direct Start-Process path rather than opening the registered codex://threads/... protocol handler.

So the failure mode appears unchanged in 0.142.0, and the protocol-handler based candidate fix linked above still seems applicable.

Steven13799 · 11 days ago

Confirmed on a separate Windows 11 Pro x64 machine with the current releases; this is still reproducible in the latest npm CLI.

Environment

Windows 11 Pro, build 26200, x64
Codex CLI: 0.144.0 (npm; also the current latest tag)
Codex Desktop MSIX: OpenAI.Codex 26.707.3351.0
Auth: ChatGPT account

Reproduction

Start a Codex CLI TUI session.
Run /app.
The handoff fails with:

Failed to open this session in Codex Desktop: Start-Process : This command cannot be run due to the error: Access is denied.
...
FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Checks performed

codex doctor --summary: 17 OK, 0 warnings/failures; authentication, config, networking, and installation are healthy.
Get-AppxPackage OpenAI.Codex reports status Ok.
Get-StartApps returns OpenAI.Codex_2p2nqsd0c76g0!App.
Standard MSIX activation works:

Start-Process 'shell:AppsFolder\\OpenAI.Codex_2p2nqsd0c76g0!App'

The registered protocol works:

Start-Process 'codex://threads/new'

This reinforces that Desktop is correctly installed/registered and that the regression is specifically the CLI /app handoff path. The protocol handler is viable while direct execution from the protected MSIX/WindowsApps package is not.

No Defender Controlled Folder Access or comparable local execution protection is enabled on this machine.

starriet9 · 8 days ago

Thanks @Steven13799 for independently reproducing the same /app launch failure on Windows 11 with an npm-installed codex-cli 0.144.0. That confirms the failure is not limited to Windows 10 or the standalone installer.

I refreshed the candidate branch onto current main (9e552e9d1, checked on 2026-07-12) and reran the Windows regression coverage.

I also inspected the current official Desktop registration on the original Windows 10 machine:

Package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
Publisher ID: 2p2nqsd0c76g0
Manifest executable: app/ChatGPT.exe
Registered protocol: codex
Package status: Ok

The current branch:

requires the stable package name OpenAI.Codex and official publisher ID 2p2nqsd0c76g0, so the handoff does not depend on the Start-menu display name (Codex versus ChatGPT)
opens the existing codex://threads/<thread_id> URL with Start-Process -FilePath $url
does not construct or directly launch WindowsApps\...\Codex.exe, ChatGPT.exe, or resources\app.asar

Branch:

https://github.com/starriet9/codex/tree/fix/windows-app-open-thread-protocol

Current commit:

https://github.com/starriet9/codex/commit/dc201e893081a957c12f1013c26e22b2024641b2

Validation on Windows:

just test -p codex-tui windows_desktop_app_launch_uses_protocol_handler
just test -p codex-tui
just fix -p codex-tui
cargo fmt --all -- --check
git diff --check origin/main...HEAD

The targeted regression test, Clippy fix pass, rustfmt check, and diff check all passed. The full codex-tui run passed 2,969 of 2,972 executed tests, with 9 additional tests skipped. The three failures are unrelated status::helpers path-display tests; the same failures were reproduced from unmodified main in the same environment, and the subsequent upstream commits do not touch those paths.

I also ran the exact generated Windows PowerShell launch path against the current package above. Registered-protocol activation completed successfully with Desktop initially stopped and again with Desktop already running. On cold start, Desktop displayed the same thread and its content through the launch point. The previous direct-executable Access is denied error did not occur.

The package identity check follows the same Windows package-name and publisher-ID policy proposed in the closed maintainer PR #28253. A shared Desktop discovery component would be a useful longer-term direction for /app and codex app; this candidate intentionally stays focused on the TUI handoff failure.

This supersedes the candidate-implementation details in the original issue's Additional information section; the original 0.140.0 reproduction remains unchanged. If this direction matches the intended Windows Desktop handoff, the focused branch is ready for a PR invitation.

EarzuChan · 8 days ago

Same with you! Your fix pr should be merged