Windows Codex Desktop: Chrome profile detection and AppX launch conflict with Chrome

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

• #28584

Powered by Codex Action

Thanks. I reviewed #28584. It seems related to the Chrome extension/native messaging/profile-detection area, but I do not think this issue is a full duplicate.

#28584 is about Chrome Beta on macOS where the native messaging host is created only for Stable Chrome.

My case is on Windows with stable Google Chrome, where the Chrome user data directory has been moved to D:\Chrome\User Data. The Codex Chrome plugin appears to check the default Windows Chrome profile path instead.

This issue also includes a second Windows-specific problem: launching Codex from the Windows Start Menu/AppX entry while Chrome is already running opens or focuses a Chrome window instead of Codex. Directly launching Codex.exe with an explicit Codex user data directory does not reproduce that behavior.

So #28584 may be related, but this issue tracks Windows profile-path detection and AppX/Start Menu launch behavior specifically.

Update: I found the final root cause and resolved the issue on my machine.

The problem was caused by two global Windows user environment variables that I had set while trying to make the Chrome MCP/plugin detect my moved Chrome profile:

CODEX_CHROME_USER_DATA_DIR=D:\Chrome\User Data
CODEX_CHROME_PREFERENCES_PATH=D:\Chrome\User Data\Default\Preferences

Codex/ChatGPT Desktop is itself a Chromium-based AppX desktop app. Because these variables were set globally at the Windows user level, the desktop app inherited them on startup and ended up using my regular Chrome profile directory. That made Codex/ChatGPT open as, or look like, a normal Chrome window instead of its own desktop app window.

Fix:

1. Open Windows Environment Variables.
2. Remove these two variables from the global/user environment:

• CODEX_CHROME_USER_DATA_DIR
• CODEX_CHROME_PREFERENCES_PATH

1. Reboot Windows.
2. Launch Codex/ChatGPT Desktop again from the Start Menu.

After removing the global variables and rebooting, the desktop app launches normally again as an independent Codex/ChatGPT window.

Important note: these variables should not be set globally. If they are needed for a Chrome MCP server / Codex CLI workflow, they should be scoped only to that specific MCP server or CLI process, for example under that server's local env configuration, not in the Windows user environment.

Environment where this was fixed:

Windows 11 Pro 10.0.22631
Codex/ChatGPT AppX 26.707.3563.0
Google Chrome Stable with user data moved to D:\Chrome\User Data

Follow-up: a second, distinct Windows cause after the environment-variable fix

The previous update fixed the global CODEX_CHROME_USER_DATA_DIR / CODEX_CHROME_PREFERENCES_PATH cause. After updating the AppX package to 26.707.3748.0, I saw the same visible symptom again even though both variables were confirmed absent.

New evidence

• Running the packaged ChatGPT.exe directly starts the normal standalone Electron window. The application package itself is healthy.
• Start-Process 'codex://test' opens Google Chrome instead of the desktop app.
• HKCU\Software\Classes\codex existed, but its shell\open\command subkey was missing. This user-level, incomplete protocol key prevented Windows from routing codex:// to the packaged desktop app.
• My Chrome profile's Preferences file had an allowed protocol-handler entry for the Codex extension (hehggadaopoacecdllhhajmbjkdcmajg) that allowed it to handle codex.

This produces the following path:

Start Menu / AppX activation
  -> activation triggers codex://
  -> incomplete HKCU\Software\Classes\codex masks the desktop protocol handler
  -> Chrome extension is allowed to handle codex://
  -> Chrome opens instead of the Codex/ChatGPT desktop window

Resolution / workaround

1. Close every Chrome window.
2. Back up D:\Chrome\User Data\Default\Preferences.
3. Delete only the incomplete per-user protocol override (no elevation is required for HKCU):

``powershell
Remove-Item 'HKCU:\Software\Classes\codex' -Recurse -Force
``

This removes the broken user override so that the packaged app's protocol registration can be used again.

1. In the backed-up Chrome profile's Preferences, remove the codex allowance for the extension under:

``text
protocol_handler.allowed_origin_protocol_pairs
-> chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg
``

Keep the JSON valid, then start Chrome again.

1. Launch Codex/ChatGPT from the Start Menu and verify that it opens its own desktop window. As an additional check, Start-Process 'codex://test' should no longer be taken over by Chrome.

This is related to the original AppX/Chrome launch symptom, but it is distinct from the earlier global-environment-variable cause: in this case the desktop executable never started through the Start Menu path because codex:// had been intercepted.

I can reproduce this on a newer Codex Windows build, and I captured deterministic AppX activation traces that may help narrow this down.

Environment

• Codex package: OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0
• Windows 11 x64, build 22631
• Chrome: 150.0.7871.187
• Chrome executable: C:\Program Files\Google\Chrome\Application\chrome.exe
• Chrome user-data directory: D:\Apps\ChromeData (non-default location)
• Codex AUMID: OpenAI.Codex_2p2nqsd0c76g0!App

Reproduction

1. Fully close Codex.
2. Start Chrome and leave it running.
3. Launch Codex from its Windows desktop shortcut / Start menu (AppX activation).
4. Chrome remains or returns to the foreground, while no Codex window appears.
5. Process tracing shows that a Codex process is created, then exits after about 2 seconds.
6. Close Chrome and launch Codex first: Codex starts successfully. Chrome can then be opened and both applications coexist.

This is repeatable and depends on application start order.

Activation evidence

IApplicationActivationManager.ActivateApplication returns S_OK (0x00000000) and a valid PID, but the activated process exits before creating a window:

09:37:50.251 CODEX_ACTIVATION_REQUESTED attempt=1 hresult=0x00000000 pid=26592
09:37:52.279 ACTIVATED_PROCESS_EXITED attempt=1 pid=26592 ageSeconds=2.1
09:37:54.364 CODEX_ACTIVATION_REQUESTED attempt=2 hresult=0x00000000 pid=12700
09:37:56.313 ACTIVATED_PROCESS_EXITED attempt=2 pid=12700 ageSeconds=2.0

A separate run produced the same ~2-second exit on the first three attempts. A fourth activation eventually stayed alive and created the Codex window.

Windows AppModel-Runtime logs show successful activation/container creation (events 201, 210, and 211), followed shortly by container destruction (event 217). There is no corresponding conventional Application Error or WER crash event.

Isolation already attempted

• Re-registering the AppX package did not fix the behavior.
• Launching through the official AppX activation API did not fix it.
• Window-focus/restore logic does not address the root issue because the Codex process itself exits before its window appears.
• Third-party IME modules were observed in both Chrome and Codex, but an attempted component isolation only caused the IME to load an older module version; there is not enough evidence to attribute the bug to the IME.

This looks closer to a Chromium profile/singleton or AppX startup conflict involving Chrome's non-default user-data directory than a simple foreground-window issue.

Expected behavior

Codex should launch with its own isolated Chromium profile/singleton regardless of whether Chrome is already running.

The log excerpts above are sanitized; I can provide additional sanitized AppModel-Runtime timing data if useful.