[Feature Request] Claude Desktop: Option to execute commands in WSL instead of Windows

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This is still a highly desirable feature request.

Same situation here — my entire dev environment lives in WSL, but I want Claude Desktop's UI for viewing images, reading documents, and voice input.

An alternative approach: instead of making Claude Desktop execute in WSL directly, what if Claude Code could open its sessions in Desktop?

Something like:

# In WSL terminal
claude --desktop

This would open Claude Desktop with the session selector, showing your existing Claude Code sessions. Pick one, and Desktop becomes the UI for that session — you can keep using it just like Claude Code, running commands, editing files, approving permissions, everything. The execution happens in WSL, Desktop is just the interface.

The biggest win: approving permissions from anywhere. Start a long task in WSL, then approve permissions from Desktop or even your phone without being glued to the terminal.

This might be simpler to implement than deep WSL integration, and it would benefit users beyond just Windows/WSL — anyone who wants to switch between terminal and Desktop mid-session.

Related: #15881

One more request for this feature please!

Hi Folks! I have done a workaround for now, it is not perfect but it might work as a temporary fix until Anthropic gives us the option to execute in WSL. I have asked Claude to create a good simple/didactic tutorial for it, and there it is:

(If someone has a better way to do it, I am all ears) Tks folks

Running Claude Desktop with WSL2

Claude Desktop on Windows uses Git Bash for command execution. That means no access to your Linux toolchain — no native Python, no apt, no GPU compute. This guide fixes that with a two-line bash profile hack that transparently forwards all commands to WSL2.

After setup, you keep the Claude Desktop GUI on Windows and everything runs in Linux.

What you need

Windows 10/11 with WSL2 and a distro (Ubuntu, etc), Claude Desktop, and Git for Windows. You probably have all of these already.

1. Enable systemd

Edit /etc/wsl.conf inside WSL:

[boot]
systemd=true

[user]
default=yourusername

Restart WSL from PowerShell with wsl --shutdown.

2. Keep WSL alive

Claude Desktop doesn't hold a persistent wsl.exe process — it fires one per command. Between commands, Windows sees no active WSL process and terminates the entire VM. Next command? Cold boot. This makes everything painfully slow and can drop state.

Two things fix this. First, edit %USERPROFILE%\.wslconfig:

[wsl2]
vmIdleTimeout=-1

Second, create a startup script that holds a background process inside WSL. This is what actually keeps the VM warm. Open PowerShell:

[System.IO.File]::WriteAllText("$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\wsl-startup.vbs", @'
Set objShell = CreateObject("Wscript.Shell")
objShell.Run "wsl -d Ubuntu --exec sleep infinity", 0, False
WScript.Sleep 15000
objShell.Run "subst W: \\wsl.localhost\Ubuntu\home\yourusername", 0, False
'@)

The script does two things on login: runs a hidden sleep infinity in WSL (zero CPU, just keeps the VM from being killed), then maps a W: drive to your WSL home so Claude Desktop's file picker can browse it. The 15-second wait gives WSL time to fully boot before the drive mapping happens.

Replace yourusername with your WSL username.

3. The bash profile

This is the entire trick. When Claude Desktop runs a command, it calls Git Bash with bash -lc "command". Git Bash sets a variable called $BASH_EXECUTION_STRING with that command. We intercept it and re-run it inside WSL.

[System.IO.File]::WriteAllText("$env:USERPROFILE\.bash_profile", @'
if [ -n "$BASH_EXECUTION_STRING" ]; then
    WSL_CWD=$(pwd | sed 's|^/w/|/home/yourusername/|; s|^/W/|/home/yourusername/|')
    CMD=$(echo "$BASH_EXECUTION_STRING" | sed -e 's|W:\\\\|/home/yourusername/|g' -e 's|W:/|/home/yourusername/|g' -e 's|/w/|/home/yourusername/|g' -e 's|/W/|/home/yourusername/|g')
    exec wsl.exe -d Ubuntu --cd ~ -- bash -lc "cd '$WSL_CWD' 2>/dev/null; $CMD"
fi
'@, [System.Text.UTF8Encoding]::new($false))

Replace yourusername in all three places. The UTF8Encoding($false) matters — without it, PowerShell adds a BOM that Bash interprets as a broken command.

The sed lines translate Windows-style drive paths (W:\, /w/, /W/) back to real WSL paths. Claude Desktop sees the project through the W: drive, so it sometimes generates these in commands. The translation catches them before WSL chokes on them.

Interactive Git Bash sessions are unaffected — they don't set $BASH_EXECUTION_STRING, so the if block never fires.

4. Reboot

Restart your PC. The startup script boots WSL, keeps it alive, and maps W:. If Explorer shows W: as "disconnected network drive", it works fine (although I would like to not see this, but yeah, it works for now, we will not give so much attention for something that might be useless in a couple months).

5. Open a project

Open Claude Desktop, start a local session, and navigate to W:\ in the directory picker. Select your project folder. All bash commands now run in WSL2.

6. Tell Claude about the environment

Drop a CLAUDE.md in your project root:

# Environment
- WSL2 Ubuntu, use Linux paths and commands
- Never use Windows paths (W:\, C:\) in bash
- W:\ maps to /home/yourusername/ for file tools only, not bash

This nudges Claude to generate Linux-native commands from the start, so the path translation rarely needs to kick in.

Verify

Ask Claude Desktop to run uname -a. If you see Linux ... microsoft-standard-WSL2, it worked. If you see MINGW64, something went wrong with the bash profile — check that the file exists at C:\Users\<you>\.bash_profile and has no BOM.

I can't believe this isn't done. My Claude for Windows just shows "Failed to load session" for any prompt - likely because Git Bash is missing. But who uses Git Bash when you have WSL2? My whole setup is in WSL, naturally this is where I run Docker from, and this is where all the work lives. Of course, it has Git installed too.

Has anyone tried the workaround by @dequeirozrodriguez? It seems complex and not very streamlined, so I'd like to know that it works (and supports my usecases) before I try something like that.

The latest version of claude code on windows allows ssh into remote. I'm able to remote into my wsl and access folders. There's a bug that means I can't submit prompts for some reason but I'm hoping that's trivial and they fix it soon and that this will enable it all to work smoothly. I'm going to wait for that rather than use the workaround. You can add comments to that bug report if you think it will help you: https://github.com/anthropics/claude-code/issues/27325#issuecomment-3950717407

waiting for a solution from Anthropic

WSL support would bring a ton of usefulness to to the Claude Desktop on windows! 👍 for claude --desktop

#wsltoo i REALLY want to use claude desktop for claude code, love the better UX but sadly when developing in WSL currently its just impossible ...

+1 on this. My entire dev stack is in WSL2, and I'd love to explore the Claude Desktop experience.

I've been moving things to WSL lately myself, due to better tooling support for things. I also wish there was a native way for Claude Desktop with WSL, hope this comes soon!

In the meantime, I built an MCP tool for Claude Desktop that interfaces through WSL. Has common commands so you can at least use the Chat window with it, but will not work with the Claude Code tab of it, sadly. Also a tool call to pipe a prompt/plan/etc into Claude Code in WSL and let it do it's thing and get the result back. It will use all of your existing tooling.

I've been using it during testing and it's pretty natural feeling even if it's not Claude Code directly. If you find it useful, cool, if not, cool too. Just wanted to share something that works, at least for me, until a more native solution comes along.

Give the Readme a review, it's all transparent and open in what it is/isn't.

https://github.com/Kyle-Undefined/gandr

I have had the same requirement - Using Claude Code in Claude Desktop to work on projects hosted in WSL. Turns out that Claude CLI's Remote Control feature works perfectly for this.

In WSL in your project directory, run claude remote-desktop. Then in Claude Code in the Desktop app, click on the Local drop-down and Add remote control. You should be able to connect to the Claude CLI session running in WSL.

From my initial experience, it gives me full access from Claude Desktop to everything that Claude CLI can do, including running commands, etc.

Proper WSL integration would be nice, but this is an acceptable work-around in the meantime.

The latest version of claude code on windows allows ssh into remote. I'm able to remote into my wsl and access folders. There's a bug that means I can't submit prompts for some reason but I'm hoping that's trivial and they fix it soon and that this will enable it all to work smoothly. I'm going to wait for that rather than use the workaround. You can add comments to that bug report if you think it will help you: #27325 (comment)

I feel like this response from @antonyevans got buried somehow in this thread, but I'm reposting it here because it seems to be the answer to what folks are looking for. I configured claude desktop/code to SSH into my WSL instance and its working perfectly. It's not quite a native solution, but with only a few steps I was able to get it up and running and I think it's what folks are looking for.

Enabling SSH into WSL instances is nontrivial, it's also blocked on https://github.com/anthropics/claude-code/issues/27325 which has been closed as not planned.

I just opened a Claude subscription to see how it compares to OpenAI, can't believe that I basically can't use the desktop app at all.

I was so happy seeing the new desktop app, only to realize this STILL hasn't been addressed...
Come on Anthropic.

This has top priority for us.

Windows + WSL2 is a very common developer set-up which simply needs support.

u cant expect a feature which is in other softrware since like ~2019 in a brand new developer tool xD

but ofc a user can figure it out in ....

Please Anthropic, make it happen!

yes @claude we want this

+1 for this please
what we have now is great but there's friction using claude in WSL - voice, copy/paste screenshots etc.
the desktop app is a much nicer experience and it can run WSL commands, code and work out of WSL if instructed to do so - but it's not optimal either

some way to bridge these gaps or even have claude desktop app make it's own WSL like docker desktop and integrate with other WSLs too would be great

Author here — consolidating state 5 months in:

Workarounds that surfaced in the thread:

• claude remote-desktop from WSL (@robmeijer, March) — works but manual every session
• WSL MCP bridge (@Kyle-Undefined) — partial coverage
• SSH→WSL on localhost — additionally limited by UI bugs (#27325 was closed as not planned), making this workaround impractical

What hasn't changed in 5 months: Windows + WSL2 is the default modern dev setup on Windows. Comments here have been consistent — entire dev stacks live in WSL, Claude Desktop UX is better than terminal (voice input, screenshot paste, nicer interface), and none of the workarounds feel like real solutions.

80 👍, 21 comments, zero triage response. Could someone from Anthropic give a signal on this? Even "not planned, here's why" would help the community stop speculating and plan accordingly.

There was another feature request just opened, similar to this https://github.com/anthropics/claude-code/issues/49933

There is a great need in the development community to use VS Code-like thing client capabilities, so that all configurations and projects are stored in WSL and Windows UI is just a thin client

Guys, chill, its not a multi mrd dollar company. ;-)

I millionth second this.

+1 we need this feature

Absolutely required.

+1 need this feature, game changer if implemented correctly

+1 we need this

Atleast we know they dont give a f.

I truly wonder, are WSL devs such an insignificant part of the Claude Code userbase , that they choose to just ignore this?

Sort of exposes the lie that "AI" assisted development is as magical as everyone claims. Should be trivial to tell Claude to implement this...

App is still useless on Windows without this... Been enjoying T3code but now the actually good client apps are going to be unable to use our subscriptions...

Will be moving to Codex unless great strides are made here or the decision is reversed to allow other clients to continue using the agent SDK

any updates 👍

App is still useless on Windows without this... Been enjoying T3code but now the actually good client apps are going to be unable to use our subscriptions... Will be moving to Codex unless great strides are made here or the decision is reversed to allow other clients to continue using the agent SDK

Fully agree. Like why in codex it was day 0 features, but in Claude Code it is not? A now the better app, T3Code going to stop working as well.

yes, please. one fix to unlock so many use cases…

I found a workaround but I'm not sure if it fits your use case but you can essentially use Claude Code for the desktop by installing the Claude VSCode extension and connecting to WSL via the Command Interface in VSCode, or you could also natively install claude via npx via the terminal.

ask claude on windows to create ssh connection to WSL with seperate account on WSL Linux Distro for Claude. Then in Claude Desktop SSH into WSL and you'll get to use linux commands. My current setup is SSH into a VM that runs Linux through Oracle VirtualBox Manager.