Feature Request: Support WSL path translation when invoking Windows bazel.exe from WSL

[kekxv]

Subject: Feature Request: Support WSL path translation when invoking Windows bazel.exe from WSL

Summary

Hello maintainers,

I am trying to set up a development environment on Windows using code-server running inside WSL (Windows Subsystem for Linux). This setup is a workaround for code-server's limited native Windows support and works quite well.

The workflow involves running code-server in a WSL distribution and using WSL's interoperability feature to call the native Windows bazel.exe for builds. While the build process itself works, the Bazel VS Code extension does not correctly translate file paths between the Windows and WSL filesystems.

The Workflow & Problem

1. Environment:

   • Host OS: Windows
   • Development Environment: WSL (e.g., Ubuntu)
   • IDE: code-server (running inside WSL)
   • Build Tool: bazel.exe (the native Windows executable, called from within WSL)

2. Steps:

   • I open my project located on the Windows filesystem (e.g., C:\work\my-project) within the code-server instance. The path inside WSL is /mnt/c/work/my-project.
   • I use the Bazel VS Code extension to run a build or a test.
   • The extension correctly invokes bazel.exe on the Windows host.

3. Actual Behavior (The Problem):

   • When Bazel returns an error or a file path, it uses the Windows format (e.g., C:\work\my-project\src\main.cc).
   • The Bazel extension does not seem to recognize this as a valid path within the WSL context, because it's expecting a Linux-style path (/mnt/c/work/my-project/src/main.cc).
   • As a result, features like "click to navigate to file" or path-based error reporting do not work.

4. Expected Behavior:

   • The extension should detect that it is running in a WSL environment and calling a Windows executable.
   • It should automatically translate Windows-style paths from Bazel's output (like C:\work\...) into their corresponding WSL paths (/mnt/c/work/...) before processing them.

Motivation

Adding support for this path translation would enable a very powerful and seamless workflow for Windows developers. It would allow us to leverage code-server for remote development on Windows machines while still using Bazel as the underlying build system. This would be a fantastic enhancement for the Windows-based Bazel community.

Thank you for considering this feature request and for your great work on this extension

screenshot:

[cbandera]

Is there a specific reason for your "hybrid" setup? If you are working inside WSL anyway, I would assume that it is much easier, to simply install and run bazel within WSL. I.e. move your repository into the WSL filesystem and install bazel there. Would this be an option for you or is there a special need to run bazel on the Windows side?

[kekxv]

Is there a specific reason for your "hybrid" setup? If you are working inside WSL anyway, I would assume that it is much easier, to simply install and run bazel within WSL. I.e. move your repository into the WSL filesystem and install bazel there. Would this be an option for you or is there a special need to run bazel on the Windows side?

This approach is required because code-server does not support Windows, yet I need a web-accessible VS Code solution on Windows. As I lack a local Windows device, my goal is to conduct Windows-based testing through the browser.