Cannot build working VSIX from WSL2 - native binaries mismatch

[shanevcantwell]

Problem

When building the VS Code extension VSIX from WSL2, the resulting extension fails to activate with:

Error: \\?\c:\Users\...\node_sqlite3.node is not a valid Win32 application

Root Cause

The VS Code extension host runs on Windows even when connected to a WSL remote workspace. However, building the VSIX on Linux produces Linux-only native binaries (sqlite3, LanceDB, ripgrep).

The prepackage script defaults to the current platform:

[info] Using target: linux-x64

Attempted Solutions

1. --target win32-x64 - Fails because Windows dependencies (rg.exe) aren't available on Linux:

   Error: The following files were missing:
   - node_modules/@vscode/ripgrep/bin/rg.exe
   

2. Environment variable CONTINUE_VSCODE_TARGET=win32-x64 - Same issue

Impact

Developers using WSL2 (a common setup) cannot:

• Build and test local VSIX changes
• Iterate on native module-dependent features
• Verify fixes before submitting PRs

Suggested Solutions

1. Cross-platform VSIX builds - Download pre-built Windows binaries during Linux builds when targeting win32
2. Documentation - Document that WSL2 developers must use marketplace version or build on native Windows
3. Universal binaries - Include all platform binaries in the VSIX (larger but always works)

Environment

• WSL2 Ubuntu on Windows 11
• VS Code with Remote - WSL extension
• Node.js v22.17.0

Related

This was discovered while working on PR #9325 (WSL2 terminal command fix).

🤖 Generated with Claude Code

[continue]

Related Issues

Found several related issues about building, native binaries, and platform mismatches:

Native binary/platform issues:

• Continue v1.3.10-vscode win32-x64 published with corrupted esbuild.exe #7853 - Continue v1.3.10-vscode win32-x64 published with corrupted esbuild.exe
• Wrong lancedb arch version installed on macos ARM #7330 - Wrong lancedb arch version installed on macos ARM
• Error: EPERM: operation not permitted, unlink 'xxx\continue\extensions\vscode\out\build\Release\node_sqlite3.node'  #3618 - Error: EPERM: operation not permitted, unlink node_sqlite3.node (Windows build issue)

WSL-specific issues:

• Unable to debug the extension from WSL Remote (fork on main) #3764 - Unable to debug the extension from WSL Remote (fork on main)
• Unable to build the vscode or intellij locally to customize for our need. #6140 - Unable to build the vscode or intellij locally to customize for our need

Build/extension issues:

• .vsix extention don't work #8386 - .vsix extension don't work
• ERROR: npm run esbuild #3594 - ERROR: npm run esbuild

These issues share common themes around cross-platform builds, native module dependencies (sqlite3, lancedb, esbuild, ripgrep), and WSL/Windows development challenges.

[shanevcantwell]

Workaround Found

For WSL2 developers who need to test local VSIX builds:

1. Build the VSIX on Linux (as normal)
2. Install the VSIX: code --install-extension path/to/continue.vsix
3. Delete the Windows-side installation:

   rm -rf /mnt/c/Users/<username>/.vscode/extensions/continue.continue-*

4. Reload VS Code

This forces VS Code to run Continue exclusively in the WSL extension host, where Linux native binaries work correctly. The extension's extensionKind: ["ui", "workspace"] allows it to run in either host.

Why it works: The activation error occurs when the Windows extension host tries to load Linux .node binaries. By removing the Windows installation, VS Code falls back to the WSL extension host only.

Limitation: This workaround may affect scenarios where the extension needs to run UI-side operations on Windows. Testing so far shows normal functionality in WSL remote workspaces.