[Bug]: WSL Desktop runtime discovery misses CODEX_HOME/bin/wsl/<hash>/codex when service PATH has no codex #5635

Client or integration

Codex App

Area

Platform (Windows / macOS / Linux)

Summary

On OpenCodex 2.63.0, the Windows Codex Desktop + Ubuntu/WSL app-server layout can resolve the correct Windows-backed Codex home but still fail to discover the Linux Codex executable bundled by Desktop.

The Ubuntu systemd user service had no codex on PATH. The working binary was at:

/mnt/c/Users/<windows-user>/.codex/bin/wsl/<version-hash>/codex

Selecting forced v2 failed with multi_agent_v2 transition failed: Executable not found in $PATH: "codex".

This is a remaining executable-discovery gap, not a recurrence of the home-resolution fix in #63 or the service-home metadata issue #1400. Both issues were checked before filing. The proxy was running inside Ubuntu; installing a Windows CLI is not the appropriate repair.

Reproduction

1. Use Windows Codex Desktop in WSL app-server mode and run OpenCodex 2.63.0 as an Ubuntu systemd user service.
2. Have the Desktop-provided Linux binary under the effective Codex home's bin/wsl/<hash>/codex, with no standalone codex on the service PATH and no valid explicit runtime pin.
3. Check that the shared home resolver discovers the Windows-backed Codex home.
4. Attempt the v2 transition. Observe the missing executable error.
5. As a read-only A/B check, run codex --version and the absolute Desktop WSL binary's --version with the same service environment: the former fails, the latter succeeds.
6. A Desktop update can remove an older hash directory, so persisting a discovered hash without rediscovery does not solve the lifecycle problem.

At the 2.63.0 release source, src/codex/runtime.ts checks ordinary POSIX installed locations but does not enumerate the effective Codex home's bin/wsl/*/codex candidates on Linux/WSL.

A local candidate adds that discovery branch through the existing version probe while preserving explicit runtime-pin/PATH precedence and ordinary Linux/Windows behavior. Regression coverage includes absent PATH, a replaced hash directory, a valid operator pin, and an unreadable WSL candidate directory.

Version

@bitkyc08/opencodex 2.63.0, release baseline 96b1406; Codex Desktop WSL binary 0.155.0-alpha.16.

Operating system

Windows Codex Desktop host; Ubuntu 24.04.1 LTS inside WSL2; Linux systemd user service.

Provider and model

Executable discovery is provider-independent. Post-repair smoke used GPT-6 Luna and OpenRouter GLM.

Logs or error output

Before:
multi_agent_v2 transition failed: Executable not found in $PATH: "codex"

After local source repair and a user-operated proxy restart:
- current Desktop WSL binary automatically discovered and registered
- /healthz: HTTP 200
- fresh native GPT-6 Luna v2 spawn and same-child follow-up: both succeeded

Screenshots and supporting files

The local patch was tested before installation: 689 relevant tests across 12 files, zero failures; TypeScript no-emit, structure consistency, privacy scan and file-size guards passed. Five maintenance-script simulations checked installation/rollback/refusal paths. The full upstream suite was not run because this was a bounded repair of two shared mechanisms, not a PR readiness claim.

Post-install checks verified the running service and persisted runtime path. The live global forced-v2 toggle was deliberately not exercised again; base mode plus native model pins was sufficient for the communication smoke. A separate catalog-state defect is reported independently.

No raw configuration, authentication material, request bodies or private filesystem paths are attached.

Redacted configuration

{
  "multiAgentMode": "default"
}

Here default denotes the effective base selection; the stored key may be absent. No permanent PATH shim or additional Codex CLI installation was used.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.