Refactor Codex command execution to support WSL integration

[Rana-Faraz]

• Introduced resolveCodexSpawnConfig to handle command and argument resolution for Codex in WSL environments.
• Updated runCodexCommand to utilize WSL when necessary, improving compatibility on Windows.
• Enhanced terminal management to use wsl.exe for WSL workspace terminals.
• Refactored shell command normalization and candidate resolution to accommodate platform-specific behavior.
• Added tests to verify WSL fallback functionality and command execution across different platforms.

Note

Refactor server WSL launch flow and modify CodexAppServerManager.startSession, git.Layers.CodexTextGeneration.makeCodexTextGeneration, and terminal runtime to execute Codex and shells via wsl.exe for WSL workspaces

Add WSL-aware command and shell launch utilities, switch Codex CLI and app-server spawns to wsl.exe when the workspace is a WSL path, translate paths to Linux formats, and remove the publish_cli job from the release workflow.

📍Where to Start

Start with the WSL utilities in wsl.ts and then follow their use in resolveCodexSpawnConfig within codexAppServerManager.ts and terminal candidate resolution in Manager.ts.

^{Macroscope summarized dbd62bf.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 52dafe46-7e69-4997-afc8-3976f0781f91

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

🔴 Critical Layers/CodexTextGeneration.ts:244

The fallback Windows execution path sets shell: false unconditionally, but shell: true is required on Windows to spawn npm-installed CLI tools (shims like codex.cmd). When wslLaunch is null (non-WSL path), spawn("codex", { shell: false }) fails with ENOENT because the .cmd extension cannot be resolved without a shell.

Also found in 2 other location(s)

apps/server/src/codexAppServerManager.ts:590

The spawn call now unconditionally uses shell: false, replacing the previous logic shell: process.platform === "win32". This causes a regression for standard Windows usage (non-WSL) where the codex binary is a script (e.g., codex.cmd or codex.bat installed via npm) rather than a direct .exe. Without shell: true, spawn on Windows will fail to execute these scripts when relying on PATH resolution. The code should conditionally set shell to true for the native Windows fallback path, while keeping it false for the WSL execution path.

apps/server/src/provider/Layers/ProviderHealth.ts:184

The runCommand function hardcodes shell: false, removing the Windows-specific logic (shell: process.platform === "win32") that was present in the previous runCodexCommand implementation. On Windows, executing CLI tools installed via npm or other package managers typically requires a shell (or explicitly appending .cmd) because they are wrapper scripts/batch files, not direct executables. This regression will likely cause the native codex health check to fail with ENOENT on Windows, incorrectly forcing a fallback to WSL or failing entirely if WSL is unavailable.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file apps/server/src/git/Layers/CodexTextGeneration.ts around line 244:

The fallback Windows execution path sets `shell: false` unconditionally, but `shell: true` is required on Windows to spawn npm-installed CLI tools (shims like `codex.cmd`). When `wslLaunch` is null (non-WSL path), `spawn("codex", { shell: false })` fails with `ENOENT` because the `.cmd` extension cannot be resolved without a shell.

Evidence trail:
1. apps/server/src/git/Layers/CodexTextGeneration.ts lines 228-249: shows `ChildProcess.make(wslLaunch?.command ?? "codex", ..., { shell: false })` - when wslLaunch is null, uses "codex" with shell:false
2. apps/server/src/wsl.ts lines 164-169: `resolveWorkspaceCommandLaunch` returns null when `parseWslWorkspacePath` returns null
3. apps/server/src/wsl.test.ts line 31: `parseWslWorkspacePath("C:\\repo", "win32")` returns null - confirms regular Windows paths don't return WSL config
4. https://nodejs.org/api/child_process.html - "On Windows, however, `.bat` and `.cmd` files are not executable on their own without a terminal, and therefore cannot be launched using `child_process.execFile()`. When running on Windows, `.bat` and `.cmd` files can be invoked using `child_process.spawn()` with the `shell` option set"
5. apps/server/src/codexAppServerManager.ts line 591: same pattern with native spawn() and shell: false

Also found in 2 other location(s):
- apps/server/src/codexAppServerManager.ts:590 -- The `spawn` call now unconditionally uses `shell: false`, replacing the previous logic `shell: process.platform === "win32"`. This causes a regression for standard Windows usage (non-WSL) where the `codex` binary is a script (e.g., `codex.cmd` or `codex.bat` installed via npm) rather than a direct `.exe`. Without `shell: true`, `spawn` on Windows will fail to execute these scripts when relying on PATH resolution. The code should conditionally set `shell` to true for the native Windows fallback path, while keeping it false for the WSL execution path.
- apps/server/src/provider/Layers/ProviderHealth.ts:184 -- The `runCommand` function hardcodes `shell: false`, removing the Windows-specific logic (`shell: process.platform === "win32"`) that was present in the previous `runCodexCommand` implementation. On Windows, executing CLI tools installed via npm or other package managers typically requires a shell (or explicitly appending `.cmd`) because they are wrapper scripts/batch files, not direct executables. This regression will likely cause the native `codex` health check to fail with `ENOENT` on Windows, incorrectly forcing a fallback to WSL or failing entirely if WSL is unavailable.