anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 17:40:47 -05:00 by yindo · 5 comments
yindo commented 2026-02-16 17:40:47 -05:00
Owner
Copy Link
Copy Source

Originally created by @jms830 on GitHub (Dec 16, 2025).

Originally assigned to: @adamdotdevin, @Brendonovich on GitHub.

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.)
Originally created by @jms830 on GitHub (Dec 16, 2025). Originally assigned to: @adamdotdevin, @Brendonovich on GitHub. ## 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.)
yindo added the web label 2026-02-16 17:40:47 -05:00
yindo commented 2026-02-16 17:40:47 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 16, 2025):

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.

@github-actions[bot] commented on GitHub (Dec 16, 2025): 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.
yindo commented 2026-02-16 17:40:47 -05:00
Author
Owner
Copy Link
Copy Source

@Brendonovich commented on GitHub (Dec 17, 2025):

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?

@Brendonovich commented on GitHub (Dec 17, 2025): 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?
yindo commented 2026-02-16 17:40:47 -05:00
Author
Owner
Copy Link
Copy Source

@AaronFeledy commented on GitHub (Feb 4, 2026):

It would need to run the linux binary in WSL. VSCode handles this by downloading its linux binary into WSL when you enable WSL integration in the windows app.

@AaronFeledy commented on GitHub (Feb 4, 2026): It would need to run the linux binary in WSL. VSCode handles this by downloading its linux binary into WSL when you enable WSL integration in the windows app.
yindo commented 2026-02-16 17:40:47 -05:00
Author
Owner
Copy Link
Copy Source

@Brendonovich commented on GitHub (Feb 4, 2026):

Good to know, so we'll likely need to download opencode-linux-x64 and then launch that inside WSL

@Brendonovich commented on GitHub (Feb 4, 2026): Good to know, so we'll likely need to download `opencode-linux-x64` and then launch that inside WSL
yindo commented 2026-02-16 17:40:47 -05:00
Author
Owner
Copy Link
Copy Source

@Brendonovich commented on GitHub (Feb 11, 2026):

#12914 provides a toggle that will download + launch the OC server in WSL once the app is restarted, will be out in the next release.

@Brendonovich commented on GitHub (Feb 11, 2026): #12914 provides a toggle that will download + launch the OC server in WSL once the app is restarted, will be out in the next release.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label web
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3594
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?