Windows Desktop: Default app target can crash/exit after stale remote-control host is restored

What version of the Codex App are you using?

Codex Desktop 26.623.4041.0 on Windows x64.

Current process path, redacted:

C:\Program Files\WindowsApps\OpenAI.Codex_26.623.4041.0_x64__<package-id>\app\Codex.exe

What subscription do you have?

Unknown / not relevant to local crash reproduction.

What platform is your computer?

Windows x64. Locale is zh-CN. Local workspace path contains non-ASCII characters.

Redacted example:

C:\Users\<user>\Documents\<non-ascii-workspace>

What issue are you seeing?

Opening the Desktop app and then using/opening the Default app target consistently causes Codex Desktop to crash/exit. The app restarts, but the same state is restored and the issue repeats.

This does not show up as a native Windows Application Error for Codex in Event Viewer. Codex does, however, mark its Chromium profile as crashed and writes repeated Desktop logs around stale remote-control/default-target startup.

What steps can reproduce the bug?

1. Start Codex Desktop on Windows.
2. Use the top-right open target / default open location flow and open/use Default app.
3. Codex Desktop crashes/exits.
4. Reopen Codex Desktop.
5. The same state is restored and Default app remains crashy.

What is the expected behavior?

Default app should open normally, or if the persisted target points to a stale remote-control environment, Codex should fall back to local without crashing/exiting. A stale remote-control host should not poison the default Desktop open target.

What actually happens?

The persisted global state keeps selecting a stale remote-control host. After a manual edit that set selected-remote-host-id back to local, Codex later rewrote it back to the remote-control host. The Chromium profile also reverted to exit_type = Crashed.

Current observed state after the crash/restart cycle, redacted:

selected-remote-host-id = remote-control:<redacted-env-id>
electron-local-remote-control-environment-id = <redacted-env-id>
electron-local-remote-control-installation-id = <redacted-installation-id>
profile.exit_type = Crashed
profile.exited_cleanly = None
default_apps_install_state = 2

Relevant local files, paths redacted:

~/.codex/.codex-global-state.json
%LOCALAPPDATA%\Packages\OpenAI.Codex_<package-id>\LocalCache\Roaming\Codex\web\Codex\Default\Preferences
%LOCALAPPDATA%\Packages\OpenAI.Codex_<package-id>\LocalCache\Local\Codex\Logs\<date>\codex-desktop-<redacted>.log

Recent log samples, ids redacted:

2026-06-27T02:49:34.854Z info [electron-fetch-handler] codex-home request hostId=local ...
2026-06-27T02:49:34.895Z info [AppServerConnection] response_routed ... errorCode=-32603 ... method=fs/readFile ... targetDestroyed=false
2026-06-27T02:49:36.037Z info [electron-fetch-handler] codex-home request hostId=undefined ...
2026-06-27T02:49:37.278Z info [electron-fetch-handler] codex-home request hostId=remote-control:<redacted-env-id> ...

Repeated in earlier launches:

info [electron-fetch-handler] codex-home request hostId=remote-control:<redacted-env-id> ...
info [AppServerConnection] response_routed ... errorCode=-32603 ... method=app/list ... targetDestroyed=false

On an earlier run there was also a more explicit remote-control fatal log:

[AppServerConnection] app_server_connection.closed code=1073807364 ... reason="... failed to connect to app-server remote control websocket ..." ...
[AppServerConnection] fatal_error_broadcasted errorMessage="... failed to connect to app-server remote control websocket ..."

Workarounds tried

I tried a minimal local-state repair while Codex was closed/restarted:

1. Backed up Chromium Default\Preferences.
2. Changed:

profile.exit_type: Crashed -> Normal
profile.exited_cleanly: None -> true

1. Backed up ~/.codex/.codex-global-state.json.
2. Changed:

selected-remote-host-id: remote-control:<redacted-env-id> -> local

This did not persist. After reopening and reproducing the problem, Codex rewrote/restored:

selected-remote-host-id = remote-control:<redacted-env-id>
profile.exit_type = Crashed

Related issues found before filing

These look adjacent but not identical:

• #22417: Default app missing from open-target dropdown.
• #26165: Windows Desktop can crash when choosing "Open with default app" for a local file link.
• #28682: Windows zero-argument launch may fall back to Electron/Chromium default app behavior.
• #20505 / #25250 / #23339 / #24454: stale selected-remote-host-id or remote-control state can poison Desktop behavior.
• #22984 / #23032 / #23038: Windows Desktop "Oops" or thread-open failures after update.

Hypothesis

The Desktop app appears to restore or recompute selected-remote-host-id from stale remote-control state, then Default app/codex-home tries to use that stale remote-control host. When the remote-control websocket or app/list/fs/readFile path fails, the app exits/crashes and marks the profile as crashed. On the next start, the crash state and stale host are restored, making the issue persistent.

A robust fix would likely be one of:

• Do not let stale remote-control:<env> become the default host for Default app when the active workspace is local.
• If remote-control connection fails, fall back to local instead of broadcasting a fatal error or exiting.
• Do not rewrite selected-remote-host-id back to a stale remote-control environment after the user/local state is reset to local.
• Surface a recoverable error in the UI and offer to reset stale remote-control/default-target state.