Fix WSL/Remote OS detection for host tools installation #202

Copilot · 2025-10-15T17:44:50Z

Problem

When running Zephyr IDE in WSL2 (Windows Subsystem for Linux) or SSH remote development environments, the extension incorrectly detected the local host OS instead of the remote OS. This caused the setup panel to suggest Windows-specific tools like winget when it should have suggested Linux tools like apt.

Example Issue:

Host machine: Windows 11
Remote environment: WSL2/Ubuntu 22.04
Host Tools panel showed: "Linux" ✓
But suggested installation: winget commands ✗ (Windows tool)

Root Cause

The extension used Node.js os.platform() API, which returns the platform where the extension host process runs. In VS Code's remote development:

Extension host runs on the local machine (e.g., Windows)
Commands execute in the remote environment (e.g., WSL/Ubuntu)
os.platform() returns "win32" (local OS) not "linux" (remote OS)

This caused platform-dependent operations to use the wrong tools and commands.

Solution

Implemented asynchronous remote environment detection using VS Code's remote development APIs:

1. Added Remote Platform Detection

Created getPlatformNameAsync() that checks vscode.env.remoteName to detect remote environments
When remote, executes uname -s to determine the actual remote OS
Caches results for performance
Falls back gracefully to local OS when not in a remote environment

2. Updated Host Tools Module

Created async versions of all platform-dependent functions:
- getPackageManagerForPlatformAsync() - Detects correct package manager for remote OS
- getPlatformPackages() - Now async to support remote detection
- All package installation operations updated to use async detection
Updated HostToolInstallView panel to use async functions

3. Fixed Python Environment Setup

getPythonCommand() now dynamically selects the correct Python command based on detected OS
- python3 for Linux/macOS
- python for Windows
Fixed PATH environment variable construction to use correct separators
- : for Unix-like systems
- ; for Windows
Virtual environment paths now use correct structure (bin vs Scripts)

4. Added Comprehensive Tests

Created platform-detection.test.ts with unit tests
Validates both synchronous and asynchronous platform detection
Ensures consistency and proper result caching

Changes

Files Modified:

src/utilities/utils.ts - Added async platform detection with remote environment support
src/setup_utilities/host_tools.ts - Updated all functions to use async platform detection
src/panels/host_tool_install_view/HostToolInstallView.ts - Updated to use async functions
src/setup_utilities/west-operations.ts - Fixed Python command selection and PATH handling

Files Added:

src/test/platform-detection.test.ts - Unit tests for platform detection

Impact

Fixed Scenarios

✅ WSL Users: Now correctly see Linux tools (apt) and commands
✅ SSH Remote Users: Correctly detect remote OS instead of local OS
✅ Dev Container Users: Improved remote environment detection
✅ Local Users: No impact, continues to work as before

Backward Compatibility

No breaking changes to public APIs
Synchronous getPlatformName() function retained for compatibility
New async functions are additive
Graceful fallback if remote detection fails

Testing

✅ All existing tests pass
✅ New unit tests verify platform detection behavior
✅ Code compiles without errors
✅ ESLint validation passes
✅ esbuild bundling successful

Fixes issue where setup panel proposed Windows tools in WSL2/Ubuntu environments.

Original prompt

This section details on the original issue you should resolve

<issue_title>Setup panel proposes to install Windows tools into WSL2/ubuntu</issue_title>
<issue_description>Describe the bug
A clear and concise description of what the bug is.

open WLS2 / ubuntu terminal

open a folder in vscode ( code ~/micropython )

Zephyr IDE > Open setup Panel

Host tools shows Linux - but proposed to install tooling via winget

Possibly the extension does not deal correctly with remote development or mixes up the local host OS with the remote host OS.
https://code.visualstudio.com/docs/remote/remote-overview

In my case:

Host OS : Windows 11

Remote OS : WSL2/Ubuntu 22.04.5 LTS

Desktop (please complete the following information):
Version: 1.103.2 (user setup)
Commit: 6f17636121051a53c88d3e605c491d22af2ba755
Date: 2025-08-20T16:45:34.255Z
Electron: 37.2.3
ElectronBuildId: 12035395
Chromium: 138.0.7204.100
Node.js: 22.17.0
V8: 13.8.500258-electron.0
OS: Windows_NT x64 10.0.26100 ( Win11)

Zephyr IDE Version: 2.0.2

Zephyr Version: 4.2 already installed

Zephyr SDK Version: already installed

Terminal: n/a - bash
</issue_description>

Comments on the Issue (you are @copilot in this section)
@rijesha Thanks for reporting the issue. I will have a look into when I have some time.

Fixes #182

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com>

…tions Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com>

Copilot

Pull Request Overview

This PR fixes WSL/Remote OS detection for host tools installation by addressing the issue where Zephyr IDE incorrectly suggested Windows-specific tools like winget when running in WSL2 or SSH remote environments. The extension now properly detects the remote OS environment and suggests appropriate tools.

Key Changes

Added asynchronous remote platform detection using VS Code's remote development APIs
Updated host tools module to use async platform detection for package manager selection
Fixed Python environment setup to use correct commands and paths based on detected OS

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
`src/utilities/utils.ts`	Added async platform detection with remote environment support using `vscode.env.remoteName` and `uname` commands
`src/setup_utilities/host_tools.ts`	Updated all package manager functions to use async platform detection instead of local OS detection
`src/panels/host_tool_install_view/HostToolInstallView.ts`	Updated UI panel to use async platform detection functions
`src/setup_utilities/west-operations.ts`	Fixed Python command selection and PATH environment variable construction for remote environments
`src/test/platform-detection.test.ts`	Added comprehensive unit tests for platform detection functionality

Copilot · 2025-10-17T14:17:13Z

src/utilities/utils.ts

 export function getPlatformName() {
+  // For remote environments, we need to detect asynchronously
+  // This synchronous function will return the cached value if available
+  if (remotePlatformCache !== undefined) {
+    switch (remotePlatformCache) {
+      case "darwin":
+        return "macos";
+      case "linux":
+        return "linux";
+      case "win32":
+        return "windows";
+    }
+  }


The synchronous getPlatformName() function now depends on a cache that may not be populated if the async version hasn't been called first. This creates an implicit dependency and could lead to inconsistent behavior. Consider documenting this behavior or ensuring the cache is always initialized.

Copilot · 2025-10-17T14:17:13Z

src/setup_utilities/west-operations.ts

+        wsConfig.activeSetupState.env["PATH"] = path.join(pythonenv, 'Scripts') + ';';
      } else {
-        wsConfig.activeSetupState.env["PATH"] = path.join(pythonenv, `bin${pathdivider}`);
+        wsConfig.activeSetupState.env["PATH"] = path.join(pythonenv, 'bin') + ':';


The PATH construction is hardcoded with string concatenation. Consider using path.delimiter from Node.js which automatically provides the correct path separator (';' for Windows, ':' for Unix-like systems) instead of hardcoding the separators.

Copilot · 2025-10-17T14:17:13Z

src/utilities/utils.ts

+    // If uname fails, try to detect Windows (though unlikely in remote)
+    const winResult = await executeShellCommand("ver", "", false);
+    if (winResult.stdout && winResult.stdout.toLowerCase().includes("windows")) {
+      remotePlatformCache = "win32";
+      return "win32";
+    }


The Windows detection using ver command is unlikely to work in remote environments (WSL, SSH to Linux), as the comment on line 73 suggests. This code path may be unreachable and could be removed or commented as a fallback that's not expected to execute.

Suggested change

// If uname fails, try to detect Windows (though unlikely in remote)

const winResult = await executeShellCommand("ver", "", false);

if (winResult.stdout && winResult.stdout.toLowerCase().includes("windows")) {

remotePlatformCache = "win32";

return "win32";

}

// If uname fails, Windows detection via 'ver' is unlikely to work in remote environments (WSL, SSH to Linux).

// The following code path is unreachable and has been removed as per CodeQL recommendation.

rijesha · 2025-10-31T15:32:50Z

Pushing this into develop for testing on pre-release. May need more modifications.

* Initial plan * Implement remote OS detection for WSL/SSH environments Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com> * Fix Python command and path separator for remote environments Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com> * Address code review feedback: fix path separator logic and test assertions Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com>

Copilot AI self-assigned this Oct 15, 2025

Initial plan

f8618f4

Copilot AI assigned rijesha Oct 15, 2025

Copilot started work on behalf of rijesha October 15, 2025 17:45 View session

Copilot AI and others added 3 commits October 15, 2025 17:50

Implement remote OS detection for WSL/SSH environments

558c613

Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com>

Fix Python command and path separator for remote environments

a215b35

Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com>

Address code review feedback: fix path separator logic and test asser…

fea6b48

…tions Co-authored-by: rijesha <7819200+rijesha@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix setup panel to recognize remote host OS in WSL2~~ Fix WSL/Remote OS detection for host tools installation Oct 15, 2025

Copilot AI requested a review from rijesha October 15, 2025 18:03

Copilot finished work on behalf of rijesha October 15, 2025 18:03

rijesha marked this pull request as ready for review October 17, 2025 14:15

rijesha requested a review from Copilot October 17, 2025 14:16

Copilot AI reviewed Oct 17, 2025

View reviewed changes

rijesha merged commit c877b8b into develop Oct 31, 2025
2 checks passed

rijesha deleted the copilot/fix-wsl2-setup-panel-issues branch October 31, 2025 15:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Fix WSL/Remote OS detection for host tools installation #202

Fix WSL/Remote OS detection for host tools installation #202

Copilot AI commented Oct 15, 2025 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Oct 17, 2025

Uh oh!

Copilot AI Oct 17, 2025

Uh oh!

Copilot AI Oct 17, 2025

Uh oh!

rijesha commented Oct 31, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Fix WSL/Remote OS detection for host tools installation #202

Fix WSL/Remote OS detection for host tools installation #202

Conversation

Copilot AI commented Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Root Cause

Solution

1. Added Remote Platform Detection

2. Updated Host Tools Module

3. Fixed Python Environment Setup

4. Added Comprehensive Tests

Changes

Impact

Fixed Scenarios

Backward Compatibility

Testing

Comments on the Issue (you are @copilot in this section)

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Key Changes

Reviewed Changes

Uh oh!

Copilot AI Oct 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 17, 2025

Choose a reason for hiding this comment

Uh oh!

rijesha commented Oct 31, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Oct 15, 2025 •

edited

Loading