[Bug] Clipboard functionality fails in WSL environment due to missing Windows executable paths

[HaD0Yun]

Summary

The clipboard functionality in OpenCode does not work correctly in Windows Subsystem for Linux (WSL) environments. The current implementation attempts to use Windows clipboard utilities but fails because the executables are not available in the default PATH within WSL.

This issue recurs with every OpenCode update, requiring users to manually patch the clipboard functionality each time a new version is released. This significantly impacts the user experience for WSL users.

Environment

• OS: Windows Subsystem for Linux (WSL2)
• Host OS: Windows 10/11
• OpenCode Version: Latest (issue persists across multiple versions)

Problem Description

The current clipboard implementation in clipboard.ts detects WSL environments but fails to access Windows clipboard utilities:

// Current implementation
if (os === "win32" || release().includes("WSL")) {
  // Attempts to call powershell.exe directly
  await $`powershell.exe -NonInteractive ...`
}

Root Cause

1. In WSL environments, powershell.exe and clip.exe are not in the default PATH
2. Bun.which("powershell.exe") returns null because these executables cannot be found
3. The clipboard operations silently fail or throw errors

Expected Behavior

Clipboard copy and read operations should work seamlessly in WSL environments, utilizing the Windows clipboard through proper executable paths.

Actual Behavior

• Clipboard operations fail because the Windows executables cannot be located
• Users must manually patch the code after every update to restore clipboard functionality
• This creates an ongoing maintenance burden for WSL users

Proposed Solution

Implement WSL-specific logic that uses absolute paths to Windows system executables:

// Helper functions to locate Windows executables via WSL mount paths
const findClipExe = (): string | null => {
  const paths = [
    "/mnt/c/Windows/System32/clip.exe",
    "/mnt/d/Windows/System32/clip.exe"
  ];
  for (const p of paths) {
    if (existsSync(p)) return p;
  }
  return null;
};

const findPowerShell = (): string | null => {
  const paths = [
    "/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe",
    "/mnt/d/Windows/System32/WindowsPowerShell/v1.0/powershell.exe"
  ];
  for (const p of paths) {
    if (existsSync(p)) return p;
  }
  return null;
};

// WSL-specific clipboard handling
if (os === "linux" && isWSL()) {
  const clipExe = findClipExe();
  const powershell = findPowerShell();
  
  // Use clip.exe for copy operations
  // Use PowerShell Get-Clipboard for read operations
}

Implementation Details

Operation	Recommended Tool	Path
Copy	clip.exe	/mnt/c/Windows/System32/clip.exe
Read	PowerShell Get-Clipboard	/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe

Impact

• Severity: Medium - Clipboard is a frequently used feature
• Affected Users: All WSL users
• Workaround Burden: Manual code patching required after every update

Additional Context

This issue affects all WSL users who rely on clipboard functionality for copying code snippets, file paths, or other content between OpenCode and Windows applications. The recurring nature of this problem after each update makes it particularly frustrating for users who depend on this functionality.

References

• WSL interoperability documentation: https://docs.microsoft.com/en-us/windows/wsl/filesystems
• Windows clipboard utilities are accessible from WSL via /mnt/c/Windows/System32/

Thank you for considering this issue. I would be happy to provide additional information or submit a pull request if needed.

[github-actions]

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

• Clipboard copy in WSL #5879: Clipboard copy in WSL

Feel free to ignore if this doesn't address your specific case.

[github-actions]

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

[Hollow1838]

Still reproduces on v1.18.11 (WSL2 + WSLg), after this issue was closed as completed. Since the body notes it recurs on every update, here is a precise root-cause breakdown.

There are actually two independent failure paths in the current clipboard.ts read logic, and on a typical WSLg setup both fail:

1. WSL → Windows clipboard path (what this issue is about). The read runs, effectively:

if (platform === "win32" || os.release().includes("WSL")) {
  // spawned by BARE command name → resolved via PATH
  spawn("powershell.exe", ["-NonInteractive","-NoProfile","-command",
    "Add-Type -AssemblyName System.Windows.Forms; $img = [System.Windows.Forms.Clipboard]::GetImage(); ..."])
}

Because it's invoked by bare name, it depends on powershell.exe being on PATH. With /etc/wsl.conf appendWindowsPath=false (common for a clean PATH), Windows executables aren't on PATH, so this throws ENOENT and is swallowed by .catch(() => Buffer.alloc(0)). The command itself is fine — calling it by full path returns the PNG.

2. Linux/WSLg fallback path. It then tries:

wl-paste -t image/png      # then: xclip -selection clipboard -t image/png -o

Both request image/png only. But under WSLg, an image copied from a Windows app is exposed on the Wayland clipboard as image/bmp (confirmed: wl-paste --list-types → image/bmp), and wl-paste does not convert, so -t image/png returns empty. X11 only has text targets. → fallback also returns nothing.

Net result: nothing is attached on Ctrl+V, regardless of keybind.

Suggested durable fixes:

• Resolve powershell.exe by absolute path on WSL (e.g. /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe, or via $WINDIR) instead of relying on PATH — survives appendWindowsPath=false.
• In the Linux/WSLg fallback, request additional MIME types (image/bmp, ...) and convert, instead of hardcoding image/png. This is essentially what feat(tui): improve clipboard paste and drag-and-drop file handling on Linux #14552 attempted, but it was closed unmerged.

User workaround (no need to re-enable appendWindowsPath) — symlink powershell into any dir already on PATH so the existing WSL branch resolves it:

ln -sf /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe ~/.local/bin/powershell.exe

After that, Ctrl+V image paste works. (If Ctrl+V is intercepted by the terminal, remap input_paste to alt+v.)

Environment: WSL2 (…-microsoft-standard-WSL2), Ubuntu 24.04, WSLg (Wayland + X11), opencode v1.18.11. Might be worth reopening.