Skip to content

[ENHANCEMENT] CLI: native Windows install and build support #1247

Description

@martin-rueegg

Problem (one or two sentences)

The Roo Code CLI can only be installed on macOS and Linux. Windows users have no installer — install.sh rejects Git Bash (MSYS/MINGW), no win32-* release artifact is built, and roo upgrade assumes a POSIX shell — so native Windows use is effectively impossible.

Context (who is affected and when)

Windows developers using PowerShell or Git Bash who want to run the CLI natively for agentic or automation workflows. Today they must fall back to WSL or hand-assemble the install, which blocks CLI adoption on the most common desktop OS.

Desired behavior (conceptual, not technical)

The CLI should install and run natively on Windows x64 with the same one-command experience as macOS/Linux: a PowerShell installer, Git Bash support, a roo.bat launcher for cmd/PowerShell, a win32-x64 release tarball, and a working roo upgrade.

Constraints / preferences

  • Function/output parity between the POSIX and Windows installers (same env vars, same progress/success messages).
  • No administrator rights required (avoid symlink creation; use a .bat shim).
  • Node.js 20+ requirement unchanged.

Request checklist

  • I've searched existing Issues and Discussions for duplicates
  • This describes a specific problem with clear context and impact

Acceptance criteria

Given a built CLI and a Windows x64 machine:

  • When I run irm https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.ps1 | iex, then roo --version and roo --help succeed from PowerShell.
  • When I run install.sh from Git Bash, then roo --version succeeds and a roo.bat launcher is generated.
  • When the release workflow runs, then it produces roo-cli-win32-x64.tar.gz containing bin/roo, bin/rg.exe, lib/index.js, and extension/.
  • When I run roo upgrade on Windows, then it invokes the PowerShell installer rather than curl | sh.
  • When I set ROO_TARBALL_SOURCE to a local path or HTTP(S) URL, then the installer uses it instead of GitHub Releases.
  • But behavior on macOS/Linux is unchanged.

Proposed approach

Already implemented and pushed to metaworx/Zoo-Code branch feat/cli-windows-support:

  • install.sh: map MSYS/MINGW → win32, handle rg.exe, generate a roo.bat launcher, and emit PowerShell PATH guidance.
  • New install.ps1: PowerShell installer with function/output parity to install.sh.
  • New scripts/build.ps1: Windows source build script (parity with build.sh).
  • cli-release.yml: add a win32-x64 build matrix entry with platform-aware ripgrep packaging.
  • Wrapper: load the CLI entry via pathToFileURL (fixes ERR_UNSUPPORTED_ESM_URL_SCHEME on Windows) and write generated files without a UTF-8 BOM.
  • upgrade.ts: select the PowerShell installer on win32.
  • Rename ROO_LOCAL_TARBALLROO_TARBALL_SOURCE (local path or URL) with the old name kept as a deprecated alias.

Trade-offs / risks

  • Deep agent-runtime Windows compatibility inside the bundled extension (shell selection for execa, TUI rendering in legacy consoles, vscode-shim path edge cases) is a separate concern beyond install/build and remains to be validated end-to-end.
  • The roo.bat launcher bakes in the absolute install path at install time; re-running the installer regenerates it, which is sufficient for the supported flow.
  • win32-arm64 is not yet in the release matrix and can be added as a follow-up.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions