WSL Codex fails after nightly update when Node is managed by nvm

[akj]

What happened

After updating T3 Code Nightly, connecting to the WSL environment consistently leaves Codex unavailable:

Codex app-server provider probe failed: Codex App Server process exited with code 1.

The existing Linux Node and Codex installations work when Linux Node is on PATH.

Diagnosis

The packaged WSL runtime changed to the standalone Linux executable in #11511. Its runtime probe captures bash -lc PATH but no longer runs the existing version-manager discovery used by the mounted Node-script runtime.

On this machine, the running WSL backend's PATH includes the Linux pnpm Codex launcher but omits the nvm Node directory. No Linux node resolves. The pnpm launcher falls back to Windows node.exe, which cannot load the Linux Codex entry point and exits with MODULE_NOT_FOUND.

The pnpm launcher explains the Windows fallback in this reproduction. The underlying missing-Node problem can also affect npm installations: npm's Linux launcher links to Codex's JavaScript entry point, which starts with #!/usr/bin/env node and needs Linux Node on PATH.

T3's executable includes its own Node, but provider CLIs still need their own runtime on PATH. Restoring the existing discovery before PATH capture fixes the provider probe without making Node a requirement for standalone T3 startup.

The affected code is in the installed release's runtime probe. It is unchanged in nightly 0.0.41-nightly.20260914.1707.

Steps to reproduce

1. In WSL, use nvm-managed Linux Node with no system node, and a pnpm-installed Codex CLI.
2. Have a noninteractive login PATH that includes the pnpm launcher directory but omits nvm's Node directory. Keep Windows Node on the inherited Windows PATH, as in this reproduction.
3. Update Windows T3 Code to the affected nightly and connect to its packaged WSL backend.
4. Check Codex provider status. It reports the exit-code-1 probe error.

The local regression test also reproduces missing nvm discovery using an isolated shell fixture, without installing Codex or contacting a provider.

Version

T3 Code 0.0.41-nightly.20260914.1700, commit 01e05c15268d.

Environment

Windows 11 Pro, build 26200. WSL2 Ubuntu 24.04.4 LTS, kernel 6.18.33.2-microsoft-standard-WSL2. Linux Node 24.15.0 managed by nvm. Codex CLI 0.154.0 installed through pnpm. Windows Node 24.20.0. Windows desktop app using its packaged WSL backend.

Evidence

The running WSL server's environment was reused for both checks, including its Windows-mounted working directory. Only the child environment's PATH changed, using the patched runtime probe's output.

Before:
  Linux node resolution: none
  Codex status: error
  Codex app-server provider probe failed: Codex App Server process exited with code 1.

After:
  Linux node resolution: <linux-home>/.nvm/versions/node/v24.15.0/bin/node
  Codex status: ready
  Codex version: 0.154.0
  Authentication: authenticated
  Models: 6
  Skills: 17

These results come from T3's actual checkCodexProviderStatus running inside Ubuntu. The desktop UI reconnect flow has not been tested with the patch.

A separate launcher check ran the existing Codex JavaScript entry point directly, as npm's Linux symlink would. With the original T3 environment it exited 127 with /usr/bin/env: node: No such file or directory. Restoring Linux Node to PATH made --version succeed with codex-cli 0.154.0. This check reused the existing package; it did not install Codex through npm.

Related issues

#8955 and #8956 concern slow skills/list calls on Windows-mounted working directories. This failure occurs during process startup, and the same working directory succeeds after repairing PATH. #7827 adds Linuxbrew to the existing resolver; this regression skips that resolver entirely for the packaged executable.

Fix applied or workaround

#11741 contains the source fix and regression tests. The installed application, shell configuration, and Node installation have not been changed. The successful runtime verification used a separate child process environment.

Filed by

GPT-6 via Codex, following the T3 Code triage playbook in the existing investigation session.

[juliusmarminge]

Thanks for the detailed repro and diagnosis — this looks like a real regression from #11511, not a Codex or nvm install problem.

What we confirmed

#11511 switched the packaged WSL backend to the standalone Linux t3 executable. The new runtime probe (probeWslRuntimeImpl in apps/desktop/src/wsl/DesktopWslEnvironment.ts) proves t3 --version and captures bash -lc PATH with resolveNode: false. It no longer runs buildWslNodeEnvPreamble() / ensure_remote_node_path, which the mounted Node-script path still uses.

That PATH is then forwarded on launch (DesktopBackendConfiguration: PATH=<system>:<resolvedPath>) so provider CLIs can be spawned by name. T3’s bundled Node is enough for the server itself; Codex/pnpm still need a Linux node on PATH. If the login PATH has the pnpm launcher but not nvm’s Node dir, WSL interop can resolve Windows node.exe, which cannot load the Linux Codex entry and exits 1 (MODULE_NOT_FOUND). That matches the reported probe error.

This is distinct from #8955 / #8956 (slow skills/list on /mnt/c cwd). #7827 only helps once this resolver runs again for the packaged executable.

Fix

#11741 already restores version-manager discovery before PATH capture and keeps standalone runtime readiness independent of Node. Review that PR rather than opening another.

Workaround until it lands

Put Linux Node on the noninteractive login PATH (for nvm: source it from ~/.profile / nvm alias default …) or install a distro Node, then reconnect to the WSL backend.