feat(desktop): Add option to run OpenCode backend via WSL on Windows

[jms830]

Summary

Windows users who prefer WSL for their development environment currently cannot use the Desktop app effectively. The Desktop app only spawns a native Windows sidecar binary, but many developers have their projects and tooling inside WSL.

Current Behavior

The Tauri desktop app spawns OpenCode as a native Windows binary via the sidecar mechanism:

• packages/tauri/src-tauri/src/lib.rs:64-91 - spawn_sidecar() always uses native binary
• packages/tauri/scripts/utils.ts:3-24 - Only defines native platform targets

Proposed Solutions

Option A: Settings Toggle (Recommended)

Add a settings UI that allows users to choose their backend:

1. Native (default) - Use bundled sidecar binary
2. WSL - Run wsl -e opencode serve --port=PORT
3. Custom command - Power users specify their own command

The setting would persist in app config and be read at startup.

Implementation:

• Enable the currently disabled Settings button in layout.tsx:536-546
• Add settings modal with backend configuration
• Modify spawn_sidecar() to check config and use appropriate spawn method
• For WSL: use Command::new("wsl").args(["-e", "opencode", "serve", ...]) instead of sidecar

Option B: Auto-Detection

Detect if the opened project folder is inside WSL (path starts with \\wsl$\ or /mnt/) and automatically use WSL backend for those projects.

Pros: Zero configuration Cons: May not match user intent, harder to implement reliably

Option C: Environment Variable Override

Support OPENCODE_BACKEND=wsl environment variable that changes spawn behavior.

Pros: Simple implementation Cons: Not user-friendly, requires launching from terminal

Additional Context

Related WSL issues (different problems):

• #693 - TUI rendering in WSL
• #595 - Paste issues in WSL terminal

This issue is specifically about the Desktop app being able to launch the OpenCode server via WSL rather than native Windows.

Use Case

1. User has projects inside WSL filesystem
2. User installs OpenCode Desktop on Windows
3. User wants Desktop UI but with OpenCode running inside WSL (for proper file access, tooling, etc.)

[github-actions[bot]]

This issue might be a duplicate of existing issues. Please check:

• #5608: [FEATURE]: OpenCode-Desktop Remote Workspace - This requests remote development support for the Desktop app, which is conceptually related to running the backend via WSL.

Feel free to ignore if your specific WSL use case differs from these requests.

[Brendonovich]

Desktop's windows build currently bundles opencode-windows-x64 to run the server. Would doing this WSL integration properly require running the opencode-linux-x64 build, or would just running the Windows binary within the WSL shell work?