Windows Desktop: no durable custom/dev bundle path equivalent to macOS for testing local app-server builds

Summary

On macOS, we can run the Codex desktop app from a custom/local desktop bundle and validate local Codex CLI / app-server changes inside the desktop UI. On Windows, I could not find an equivalent durable path: the Microsoft Store desktop app always rehydrates and launches its bundled runtime, even when the native-host manifests and local cache are patched to point at a locally built codex.exe.

This makes it difficult to validate Windows desktop behavior for app-server/core changes before those changes land in an official desktop bundle.

Environment

• Platform: Windows 11
• Codex Desktop package observed: OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0
• Bundled/runtime codex.exe observed: codex-cli 0.137.0-alpha.4
• Local custom build observed: codex-cli 0.0.0 from a local openai/codex fork/branch build
• Relevant labels: Windows desktop app, app-server, developer workflow parity

What I tried

1. Built a local Windows package from a fork branch using the repo packaging script, producing a custom codex.exe plus Windows helper executables.
2. Repointed both native-host manifest files under %LOCALAPPDATA%\OpenAI\Codex\:

• chrome-native-hosts-v2.json
• chrome-native-hosts.json

1. Verified those manifests had codexCliPath pointing at the custom package binary.
2. Stopped stale Codex.exe, extension-host.exe, and old codex.exe app-server processes.
3. Replaced the local cached runtime directory under %LOCALAPPDATA%\OpenAI\Codex\bin\fb2111b91430cb17\ with the custom codex.exe, codex-command-runner.exe, and codex-windows-sandbox-setup.exe.
4. Verified before restarting Desktop that the cache binary reported codex-cli 0.0.0 and matched the custom build hash.
5. Restarted Codex Desktop.

Actual behavior

After Codex Desktop restart:

• The native-host manifests still pointed at the custom package path.
• The local cache binary under %LOCALAPPDATA%\OpenAI\Codex\bin\fb2111b91430cb17\codex.exe had been restored to the bundled runtime (codex-cli 0.137.0-alpha.4).
• Live Desktop backend process was still launched from:
• C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\codex.exe app-server --analytics-default-enabled
• Live extension/native-host app-server processes were also using the restored %LOCALAPPDATA%\OpenAI\Codex\bin\fb2111b91430cb17\codex.exe app-server --listen stdio://.

In short: manifest patching and cache replacement were not durable; the Windows desktop app rehydrated its bundled runtime and did not run the local custom build.

Expected behavior

There should be an official Windows developer path equivalent to the macOS custom desktop bundle workflow, for example one of:

• a supported custom/dev desktop bundle install path for Windows;
• a documented runtime override for the desktop app's codex.exe / app-server binary;
• a supported way to make Desktop connect to a locally launched custom codex app-server during development;
• or documentation explicitly stating that Windows Desktop cannot run custom/dev bundles, with the intended development loop for Windows app-server/UI validation.

Why this matters

The open-source repo exposes CLI and app-server code, and codex app-server is documented as a local development/debugging surface. But if the Windows desktop app can only run the signed Store-bundled runtime, developers cannot validate desktop-visible behavior for local app-server/core changes on Windows the same way they can on macOS.

This is especially painful for app-server/context-management changes where the behavior being tested is only meaningful inside the desktop app bundle.

Additional notes

I am filing this as an enhancement/parity issue rather than a confirmed regression because I did not find public documentation promising this workflow on Windows. The key request is an official, durable developer loop for running Windows Desktop against a local/custom Codex runtime.