[Feature Request] Native WSL Remote Integration for Claude Code Desktop on Windows

Just installed Claude desktop yesterday to learn it does not integrate with claude-code running in WSL. My use cases are as follows:

1. I should be able to start Claude desktop inside WSL by running a command in shell and/or by running /desktop inside Claude code; A thin Windows client should launch using all preferences, skills and other configs from WLS.
2. I should be able to easily find Claude project directory for each project created inside Claude Desktop. This will make it easier to edit project configurations (instructions and files) using VS Code and version control them.

There is a similar request (https://github.com/anthropics/claude-code/issues/12506), however it seems this request focuses on the key need that we have (native integration into WSL) instead of just running commands remotely in WSL.

+1 on this feature request

Also just installed Claude desktop and learnt it cannot be used easily with wsl. I have a linux stack that I use for development currently with VS code and its wsl integration but I would really like to switch to claude code.

I would like to use claude desktop as a mission control for running several worktree based sessions inside WSL in multiple projects at once.

This is absolutely required. Codex already offers this as well as VSCode as mentioned by the OP.

Can we please get this on the roadmap? I love that it has ssh support but native WSL support as well would be amazing!

Considering that Claude Code is supposed to be a professional development environment, and that I sometimes get prompted to update my Claude Desktop multiple times in a single day, it's absolutely dumbfounding that this feature hasn't been included yet. Claude Desktop is basically just a toy until this feature lands.

There is a cluster of issues that makes it seem like Anthropic / Claude generally speaking does not want to support Windows/WSL connectivity. This issue, the UNC path issue referenced above, the fact that Claude Code TUI in WSL doesn't support simple copy/paste of images, etc. Please Anthropic, this should be so easy! Just have Claude implement these features! In fact has to be a PR somewhere already that gets this right... Just have Claude find it for you & merge it!

$965B Company everyone...

I should have done more research when switching to Claude.. I was a bit shocked to find no WSL nor dev container support. All of our company's projects use dev containers...

Strong +1 on this. I'm a Windows + WSL2 developer — my entire Node.js/TypeScript stack (Next.js, Prisma, Docker) lives inside WSL2, and the current Desktop experience is painful: wrong shell, broken paths, toolchain mismatches. The SSH workaround is too clunky for daily use.
VS Code's Remote - WSL solved this years ago. Claude Code Desktop deserves the same. This would unlock the Desktop UI for a huge segment of Windows developers who rely on WSL2 as their primary dev environment.

Claude CLI works nicely in WSL2, but sometimes using Claude Desktop on Windows is preferable, especially when working with documentation in Office applications. Not having access to WSL2 file system with the code is very limiting so having file system access to Ubuntu in WSL2 would be great.

+1

This should be getting more attention

My only option is to use Claude Code with VS Code, since the CLI is unusable for me due to accessibility issues. It would be great to be able to run Claude Code directly with WSL through the app without having to rely on VS Code.

CLI is unusable for me due to accessibility issues

Why is it not accessible? Security policy?

In a more "sane" interpretation running WSL2 CLI would be "safer" than running it in Windows as WSL is a virtual environment "locked in" under your Windows...

I combine VSCode and CLI... Having CLI adding a CLAUDE.md to the repository root directories seems to also have a great benefit to running it in VSCode as the Claude extension.

Nope, I mean accessibility with a screen reader, I'm blind.

Nope, I mean accessibility with a screen reader, I'm blind.

Oh, right! That makes sense! Sorry, didn't consider that option!
Respect!

Workaround: running Claude Desktop inside WSL with WSLg

I found a workaround that lets me run the Linux Claude Desktop app inside WSL2 using WSLg.

This is not the same as first-class "Remote - WSL" support in the native Windows app, but it does make Claude usable from the WSL/Linux side.

My environment:

WSL distro: Ubuntu 24.04.4 LTS
WSL version: WSL2
Architecture: amd64/x86_64
Claude package: claude-desktop 1.18286.0
GUI layer: WSLg

1. Install the Linux Claude Desktop package

I downloaded the official Linux .deb from Anthropic's apt repository and installed it inside WSL:

sudo apt install /home/<USER>/Downloads/claude-desktop/claude-desktop_1.18286.0_amd64.deb

After install:

command -v claude-desktop

returns:

/usr/bin/claude-desktop

2. Start GNOME Keyring before launching Claude

Without this, Claude warned:

Your sign-in won't be saved on this device. Install and unlock a
system keyring (such as GNOME Keyring), then restart the app.

The workaround is to start the Secret Service/keyring before launching Claude:

gnome-keyring-daemon --start --components=secrets

If the keyring is locked, unlock it:

gnome-keyring-daemon --unlock

3. Launch Claude with WSLg-friendly Electron flags

I also hit an invisible cursor issue inside the Claude window. Launching Claude with Wayland and disabling GPU acceleration fixed or improved that on my setup.

I created this wrapper:

mkdir -p ~/.local/bin
nano ~/.local/bin/claude-desktop-wsl

Wrapper contents:

#!/usr/bin/env bash
set -euo pipefail

gnome-keyring-daemon --start --components=secrets >/dev/null 2>&1 || true

export ELECTRON_OZONE_PLATFORM_HINT=wayland
export XCURSOR_THEME=Adwaita
export XCURSOR_SIZE=24

log_dir="${XDG_CACHE_HOME:-$HOME/.cache}"
mkdir -p "$log_dir"
log_file="$log_dir/claude-desktop-wsl.log"

cmd=(/usr/bin/claude-desktop --ozone-platform=wayland --enable-features=UseOzonePlatform --disable-gpu "$@")

if [[ -t 1 || -t 2 ]]; then
  setsid "${cmd[@]}" >>"$log_file" 2>&1 < /dev/null &
  printf 'Claude Desktop started. Logs: %s\n' "$log_file"
else
  exec "${cmd[@]}" >>"$log_file" 2>&1
fi

Then:

chmod +x ~/.local/bin/claude-desktop-wsl

Now I launch Claude with:

~/.local/bin/claude-desktop-wsl

4. Optional desktop launcher

I also created a user-local desktop launcher so the WSL app menu starts the wrapper instead of the raw binary:

mkdir -p ~/.local/share/applications
nano ~/.local/share/applications/claude-desktop.desktop

Contents:

[Desktop Entry]
Name=Claude
Comment=Desktop application for Claude.ai
GenericName=AI Assistant
Keywords=AI;Chat;Assistant;Claude;Code;LLM;
Exec=/home/<USER>/.local/bin/claude-desktop-wsl %U
Icon=claude-desktop
Type=Application
StartupNotify=true
StartupWMClass=claude-desktop
SingleMainWindow=true
Categories=Utility;Development;
MimeType=x-scheme-handler/claude;
Actions=NewChat;NewCode;

[Desktop Action NewChat]
Name=New chat
Exec=/home/<USER>/.local/bin/claude-desktop-wsl claude://claude.ai/new

[Desktop Action NewCode]
Name=New Claude Code session
Exec=/home/<USER>/.local/bin/claude-desktop-wsl claude://code/new

Notes

Some warnings still appear in logs under WSLg, for example:

drmGetDevices2() has not found any devices
Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
libnotify-WARNING **: Failed to connect to proxy
org.freedesktop.Notifications was not provided by any .service files

These seem to be WSLg/Electron/Linux-desktop-environment warnings rather than fatal errors. I redirect them to:

~/.cache/claude-desktop-wsl.log

Why this is only a workaround

This works well enough to launch the Linux GUI app from WSL, but it is still not ideal:

• It requires running the entire GUI app through WSLg.
• It needs manual keyring/session handling.
• It may need Electron flags for cursor/rendering issues.
• Notifications and desktop integrations are incomplete.
• It creates a separate Linux app/config/update path from the native Windows app.

The better long-term solution would still be native Windows Claude Desktop/Claude Code UI with a real WSL backend, similar to VS Code Remote - WSL:

• Windows UI stays native.
• Commands run inside the selected WSL distro.
• Linux $PATH, shell config, git config, SSH keys, package managers, and project paths are used directly.
• Opening a WSL folder can attach the native desktop UI to that WSL environment.

It may help but WSL integration would be much cleaner.

@codebytere-ant why has this been closed as completed? It isn't complete. Nothing has been done. A workaround has been posted, but even that workaround concludes:

The better long-term solution would still be native Windows Claude Desktop/Claude Code UI with a real WSL backend, similar to VS Code Remote - WSL: Windows UI stays native. Commands run inside the selected WSL distro. Linux $PATH, shell config, git config, SSH keys, package managers, and project paths are used directly. Opening a WSL folder can attach the native desktop UI to that WSL environment.

If you want to close as a won't do or not planned but don't claim it is completed.

Why is this closed?

## Workaround: running Claude Desktop inside WSL with WSLg I found a workaround that lets me run the Linux Claude Desktop app inside WSL2 using WSLg. This is not the same as first-class "Remote - WSL" support in the native Windows app, but it does make Claude usable from the WSL/Linux side. My environment: ``text WSL distro: Ubuntu 24.04.4 LTS WSL version: WSL2 Architecture: amd64/x86_64 Claude package: claude-desktop 1.18286.0 GUI layer: WSLg ` ### 1. Install the Linux Claude Desktop package I downloaded the official Linux .deb from Anthropic's apt repository and installed it inside WSL: `bash sudo apt install /home/<USER>/Downloads/claude-desktop/claude-desktop_1.18286.0_amd64.deb ` After install: `bash command -v claude-desktop ` returns: `text /usr/bin/claude-desktop ` ### 2. Start GNOME Keyring before launching Claude Without this, Claude warned: `text Your sign-in won't be saved on this device. Install and unlock a system keyring (such as GNOME Keyring), then restart the app. ` The workaround is to start the Secret Service/keyring before launching Claude: `bash gnome-keyring-daemon --start --components=secrets ` If the keyring is locked, unlock it: `bash gnome-keyring-daemon --unlock ` ### 3. Launch Claude with WSLg-friendly Electron flags I also hit an invisible cursor issue inside the Claude window. Launching Claude with Wayland and disabling GPU acceleration fixed or improved that on my setup. I created this wrapper: `bash mkdir -p ~/.local/bin nano ~/.local/bin/claude-desktop-wsl ` Wrapper contents: `bash #!/usr/bin/env bash set -euo pipefail gnome-keyring-daemon --start --components=secrets >/dev/null 2>&1 || true export ELECTRON_OZONE_PLATFORM_HINT=wayland export XCURSOR_THEME=Adwaita export XCURSOR_SIZE=24 log_dir="${XDG_CACHE_HOME:-$HOME/.cache}" mkdir -p "$log_dir" log_file="$log_dir/claude-desktop-wsl.log" cmd=(/usr/bin/claude-desktop --ozone-platform=wayland --enable-features=UseOzonePlatform --disable-gpu "$@") if [[ -t 1 || -t 2 ]]; then setsid "${cmd[@]}" >>"$log_file" 2>&1 < /dev/null & printf 'Claude Desktop started. Logs: %s\n' "$log_file" else exec "${cmd[@]}" >>"$log_file" 2>&1 fi ` Then: `bash chmod +x ~/.local/bin/claude-desktop-wsl ` Now I launch Claude with: `bash ~/.local/bin/claude-desktop-wsl ` ### 4. Optional desktop launcher I also created a user-local desktop launcher so the WSL app menu starts the wrapper instead of the raw binary: `bash mkdir -p ~/.local/share/applications nano ~/.local/share/applications/claude-desktop.desktop ` Contents: `ini [Desktop Entry] Name=Claude Comment=Desktop application for Claude.ai GenericName=AI Assistant Keywords=AI;Chat;Assistant;Claude;Code;LLM; Exec=/home/<USER>/.local/bin/claude-desktop-wsl %U Icon=claude-desktop Type=Application StartupNotify=true StartupWMClass=claude-desktop SingleMainWindow=true Categories=Utility;Development; MimeType=x-scheme-handler/claude; Actions=NewChat;NewCode; [Desktop Action NewChat] Name=New chat Exec=/home/<USER>/.local/bin/claude-desktop-wsl claude://claude.ai/new [Desktop Action NewCode] Name=New Claude Code session Exec=/home/<USER>/.local/bin/claude-desktop-wsl claude://code/new ` ### Notes Some warnings still appear in logs under WSLg, for example: `text drmGetDevices2() has not found any devices Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed libnotify-WARNING **: Failed to connect to proxy org.freedesktop.Notifications was not provided by any .service files ` These seem to be WSLg/Electron/Linux-desktop-environment warnings rather than fatal errors. I redirect them to: `text ~/.cache/claude-desktop-wsl.log ` ### Why this is only a workaround This works well enough to launch the Linux GUI app from WSL, but it is still not ideal: - It requires running the entire GUI app through WSLg. - It needs manual keyring/session handling. - It may need Electron flags for cursor/rendering issues. - Notifications and desktop integrations are incomplete. - It creates a separate Linux app/config/update path from the native Windows app. The better long-term solution would still be native Windows Claude Desktop/Claude Code UI with a real WSL backend, similar to VS Code Remote - WSL: - Windows UI stays native. - Commands run inside the selected WSL distro. - Linux $PATH`, shell config, git config, SSH keys, package managers, and project paths are used directly. - Opening a WSL folder can attach the native desktop UI to that WSL environment. It may help but WSL integration would be much cleaner.

Update: It causes WSL crash dumps(~5GB). I wouldn't recommend unless you are desperate.

I am now seeing WSL as a directly supported environment as of a recent Claude Desktop update. I've been using it today instead of my previous SSH based solution, and so far so good.

<img width="385" height="428" alt="Image" src="https://github.com/user-attachments/assets/f9ccc516-cb10-436f-a5fc-2954d3fc2ed0" />

hey folks just shipped this - throw feedback my way!

hey folks just shipped this - throw feedback my way!

Thanks for that feature, it feels so good using it. However, here is a few feedback I have to give so that I won't ever have to open my terminal again.

• Having the terminal integration where it's just a sidebar, the same way we have for native windows, would be very cool.
• When opening the file explorer to choose a path, in my opinion, it would be better to start at the home dir of the user rather than at the root of the file system.
• And I don't know if it's related to this implementation, but being able to keep the permission option that we last used in this environment carry over to a new session would be great.