[Bug]: Codex provider probe times out on WSL when server cwd is on /mnt/c drvfs

Summary

On T3 Code desktop with the WSL backend enabled, the Codex provider can show:

Unavailable · Timed out while checking Codex app-server provider status.

Codex CLI itself works fine from a normal WSL shell (codex login, codex app-server, etc.).

Environment

• Windows + WSL2 (e.g. Arch Linux)
• T3 Code desktop, WSL-only / WSL backend enabled
• Codex CLI installed in WSL (e.g. ~/.local/bin/codex)

Root cause

When the desktop launches the backend inside WSL, the server often runs with process.cwd() on a Windows profile path mounted under /mnt/c/... (drvfs).

During provider status checks, checkCodexProviderStatus passes cwd: process.cwd() into probeCodexAppServerProvider, which calls Codex skills/list with that cwd.

Reproduction from WSL:

• skills/list with cwd /home/<user> → completes in ~0.1s
• skills/list with cwd /mnt/c/Users/<windows-user> → hangs >12s
• Full probe timeout in T3 is 10s (AUTH_PROBE_TIMEOUT_MS) → user-visible timeout

Setting codex.binaryPath to an absolute path helps spawn but does not fix this, because the hang happens during the app-server probe, not binary resolution.

Expected behavior

Codex provider status should resolve on WSL the same as from a native Linux cwd.

Suggested fix

When process.cwd() is under /mnt/, prefer $HOME (Linux home) for Codex provider probe cwd — similar to how desktopBootstrap.t3Home is omitted for WSL because the Windows-side baseDir maps to /mnt/c/....

Workaround (until fixed)

Hot-patch the extracted WSL server tree so checkCodexProviderStatus uses $HOME instead of process.cwd() when cwd starts with /mnt/. This is not durable across T3 reinstall/update because the runtime is re-extracted from wsl-runtime.tar.gz.

Locate checkCodexProviderStatus and probeCodexAppServerProvider in the TypeScript backend, then trace how process.cwd() is passed into the Codex skills/list probe. Reproduce the probe with a WSL cwd under /mnt/ and a Linux home cwd. Done means the provider status resolves within the existing timeout when the server starts from a Windows-mounted WSL path.