-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Description
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 binarypackages/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:
- Native (default) - Use bundled sidecar binary
- WSL - Run
wsl -e opencode serve --port=PORT - 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):
- /editor: non-successful editor exits should keep the text in the textarea #693 - TUI rendering in WSL
- fix: Copilot Premium Requests #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
- User has projects inside WSL filesystem
- User installs OpenCode Desktop on Windows
- User wants Desktop UI but with OpenCode running inside WSL (for proper file access, tooling, etc.)