Cluade Code in Windows is a pain in ***

[mohamedyassin07]

You must support Windows directly or make a middle solution to make the situation easier

We need to install the MCP in the WSL so it can't access Windows resources

• Claude's code can't fetch/curl localhost windows websites
• MCP servers can't use Windows tools, and one of the most important is the browsers, so we can't make automation tests easily

PLEASE MAKE A SOLUTION

[sbrkopac]

While I agree we could use more native windows support. WSL2 can access your local windows file and it can also curl against the windows host IP or the machine name.

[barneyferry]

+1 it seems the tool is already written in a cross-platform language (JS) and it's not doing anything platform specific so a native windows release would be good.

I hop between windows and mac for both work and personal, I generally do a lot of dev work on windows so this is a blocker as it only works on one of my machines.

I'd be happy to help develop/test a proper cross platform version.

[clark-stevenson]

Yeah I would definitely love to see this. I got access to a max account yesterday and I am still trying to get vitest watch to work. It's incredibly frustrating 😅

[jonathanlal]

I'm trying to get the same servers on WSL & Windows but proving difficult. Is it just me? Docker came out with a new MCP Toolkit - but can't hack it

[dkmaker]

You must support Windows directly or make a middle solution to make the situation easier

We need to install the MCP in the WSL so it can't access Windows resources

• Claude's code can't fetch/curl localhost windows websites
• MCP servers can't use Windows tools, and one of the most important is the browsers, so we can't make automation tests easily

PLEASE MAKE A SOLUTION

Wondering what the issue is? You have interop and all works together - I have had no issues using it across - windows folders is mounted in /mnt/c and well curl calls to local host is working - docker desktop is WSL integrated and VSCODE works with remote and also with Claude - so really can't see any issues - all I do is remove so path is not merged - but path the needed folders in windows

The thing is Linux have a ton of tools like awk jq rg grep find etc that claude code use ALOT - And Linux is just so much more in general dev friendly and well documented - that is a big thing why claude code is so powerful

[mohamedyassin07]

You must support Windows directly or make a middle solution to make the situation easier We need to install the MCP in the WSL so it can't access Windows resources

• Claude's code can't fetch/curl localhost windows websites
• MCP servers can't use Windows tools, and one of the most important is the browsers, so we can't make automation tests easily

PLEASE MAKE A SOLUTION

Wondering what the issue is? You have interop and all works together - I have had no issues using it across - windows folders is mounted in /mnt/c and well curl calls to local host is working - docker desktop is WSL integrated and VSCODE works with remote and also with Claude - so really can't see any issues - all I do is remove so path is not merged - but path the needed folders in windows

The thing is Linux have a ton of tools like awk jq rg grep find etc that claude code use ALOT - And Linux is just so much more in general dev friendly and well documented - that is a big thing why claude code is so powerful

whatever you added in CLAUDE.md file, in long converstions claude will forget alof or memories so he will go with the defalut attitude so automated testing will be a HELL, use it for more than month/or even less in a real project and you will find it's not about just code writing

[dkmaker]

You must support Windows directly or make a middle solution to make the situation easier We need to install the MCP in the WSL so it can't access Windows resources

• Claude's code can't fetch/curl localhost windows websites
• MCP servers can't use Windows tools, and one of the most important is the browsers, so we can't make automation tests easily

PLEASE MAKE A SOLUTION

Wondering what the issue is? You have interop and all works together - I have had no issues using it across - windows folders is mounted in /mnt/c and well curl calls to local host is working - docker desktop is WSL integrated and VSCODE works with remote and also with Claude - so really can't see any issues - all I do is remove so path is not merged - but path the needed folders in windows The thing is Linux have a ton of tools like awk jq rg grep find etc that claude code use ALOT - And Linux is just so much more in general dev friendly and well documented - that is a big thing why claude code is so powerful

whatever you added in CLAUDE.md file, in long converstions claude will forget alof or memories so he will go with the defalut attitude so automated testing will be a HELL, use it for more than month/or even less in a real project and you will find it's not about just code writing

I still don't see the issue is related to WSL / Linux - that is how you use it - you are probably not adopting commands and workflows - but that still have nothing to do about the Claude code in Windows issue you refer to

I have spend probably more than 1000$ in consumption and now on 2. month max plan 200$ and is using it more less 5-8 hrs a day and all is produced via WSL on Windows and i have had exactly no issues making C# applications etc. all is working just fine in interop even better than other agents because its backed by all the linux tools so its WAY more efficient at handling debug and testing etc.

Of course it will have its limits on Windows desktop app deployment but - who is making that anymore

To solve the issue you refer to you should use custom slash commands to make workflows that actually make sure your process is handled across context reset - or after /compact - but that is exactly the same issue with all other coding agents - they forget very fast - you cant really rely on memory when context window goes beyond 80% or so - probably already at 70% it stops - my workflow is compact after each feature then a new / command i use for feature, bug hunting etc. that define exctly how i want it to lint, make code quality checks before and and after and then it should commit and make branch etc..

That works VERY well -

The ONLY thing i have issues with is the SHIFT-Enter to new line - thats a real pain its not working in WSL :-/ but that is the only issue i have at all - but that is so anoying - its actually anoying it cant default to new line and then shift return on complete like all other services do..

[barneyferry]

Windows desktop app deployment but - who is making that anymore

me, and many people, still the most widely used OS in the world :)

there's a lot more to building some software than just running some "ls" commands - which pretty much all shells on all platforms alias to the platform equivalent (e.g. on Windows + PowerShell it's Get-ChildItem)

As far as I can tell, Claude Code is already written in a cross-platform language (JavaScript?) so cross-platform is not a tooling issue, it's most likely just a product issue, shipping to one platform first to save time.

Ultimately, for market penetration, cross-platform is a must. Not everyone uses a Linux VM, I don't as all my work is cross-platform so I hop between Windows and Mac daily to build what I build. I use the tools of the platform rather than shoehorning things from one place to another. When in Rome and all that.

For example, I might want to run a test script that makes use of events or COM or Win32 APIs, TPM module, platform certificates, automations. All real world use-cases and Claude being stuck in a virtual machine makes it currently unusable for this kind of software. Sure, if you're throwing together a website or webapp, it can work great but that's only a portion of software development and Claude Code could be a huge help if it was opened up to a wider gamut of software development workflows.

[baadc0de]

Games and many other kinds of software that accesses hardware directly are not working well for debugging or development inside a VM. A native windows version would help.

[dkmaker]

Games and many other kinds of software that accesses hardware directly are not working well for debugging or development inside a VM. A native windows version would help.

Well they do - can you call them via a CLI then they work - you have interop så all windows paths are pathed - i have tested majority of debuggers - alså like enabling SSH via Windows so i can use 1Password ssh agent and windows SSH agent etc works perfect -

I think the majoity of the issues is people dont understand WSL - WSL is a vm yes - but the interop makes it able to run Windows processes inside - at least mine works in all cases i have had - i can even spawn the windows tool and connect to the remote debugger in chrome (Know games is proably a whole other thing

What i see is that its only because CC is using all the linux tools to search - and it should be possible to install and make a bunlde that installs jq, rg, grep, tail, head or make same set of tools in Powershell - actually thought about making a tool call library to do this also multi edits etc.

Its nice that it can use those tools - but to be honest the existing tooling is NOT good for ai - somebody should take the call and make a toolkit for AI - that can do all those advanced string maniplulation - advanced AI optimized syntax that is easy to use and have more context etc. and it should be portable - so CC and other agents can benefit of it - LLM's are good at many things but the actual string search / manipulation / replace etc. should be handled by "REAL" tools IMO - if you see retries thats often false use of a list of tools wher syntax is different and the tools dont provide proper return and error handling that is really good for the AI

[xiemobiao]

The situation I am facing now is that the company computer has encryption software installed, and I cannot access the encryption software in the Windows system from WSL. This makes coding very painful for me. I wonder when Claude Code will be able to run directly on Windows systems, as I urgently need this feature right now.

[dkmaker]

The situation I am facing now is that the company computer has encryption software installed, and I cannot access the encryption software in the Windows system from WSL. This makes coding very painful for me. I wonder when Claude Code will be able to run directly on Windows systems, as I urgently need this feature right now.

What encryption software? I use 1Password a lot - and that works fine - from the windows element with op cli tool?

You can call all windows executables directly from the WSL

[barneyferry]

What encryption software?

Most likely something that uses TPM, which while you can use vTPM to forward it, because this reduces the security posture of TPM.

I think it's clear from the use-cases outlined by a few of the people in this discussion that there are valid reasons for not wanting or even being able to virtualise certain workflows. Given the product is already built with a cross-platform language and nothing linux-specific (it's already cross-platform to Mac) it makes sense to at least ask for a fully cross platform release.

[dkmaker]

What encryption software?

Most likely something that uses TPM, which while you can use vTPM to forward it, because this reduces the security posture of TPM.

I think it's clear from the use-cases outlined by a few of the people in this discussion that there are valid reasons for not wanting or even being able to virtualise certain workflows. Given the product is already built with a cross-platform language and nothing linux-specific (it's already cross-platform to Mac) it makes sense to at least ask for a fully cross platform release.

Not that i don't agree but - i still think the majority of the cases can easily be solved with the WSL approach :-)

But yes would be nice to have a Windows native version - but still i think a lot of the success and how CC actually works with code is the fact it uses the linux tools alot and windows support for those basic tools is not as great - like rg - grep tail head etc.. Not that it could not be added like powershell commands etc. but would require basic changes and adoption

[xiemobiao]

The situation I am facing now is that the company computer has encryption software installed, and I cannot access the encryption software in the Windows system from WSL. This makes coding very painful for me. I wonder when Claude Code will be able to run directly on Windows systems, as I urgently need this feature right now.

What encryption software? I use 1Password a lot - and that works fine - from the windows element with op cli tool?

You can call all windows executables directly from the WSL

It is an encryption software deeply customized for our company. All files on the computer are encrypted into binary files, effectively isolating them from WSL. Any files read by WSL from Windows appear as garbled text.

[xiemobiao]

What encryption software?

Most likely something that uses TPM, which while you can use vTPM to forward it, because this reduces the security posture of TPM. I think it's clear from the use-cases outlined by a few of the people in this discussion that there are valid reasons for not wanting or even being able to virtualise certain workflows. Given the product is already built with a cross-platform language and nothing linux-specific (it's already cross-platform to Mac) it makes sense to at least ask for a fully cross platform release.

Not that i don't agree but - i still think the majority of the cases can easily be solved with the WSL approach :-)

But yes would be nice to have a Windows native version - but still i think a lot of the success and how CC actually works with code is the fact it uses the linux tools alot and windows support for those basic tools is not as great - like rg - grep tail head etc.. Not that it could not be added like powershell commands etc. but would require basic changes and adoption

Yes, I completely agree with your idea. Indeed, there are many scenarios that cannot be fully handled within the shell.

[barneyferry]

On tools, most things are cross platform nowadays, I use rg on my workstation machine all the time.

LLMs are text-in-text-out, "tool calls" aren't tuned to a specific OS but are just a request to run something, if an LLM wishes to run taskmgr.exe and it has the capability to do that and consent from the user, it can. There's nothing "Linux specific" about an LLM.

Sure it might have some out of the box tools or even a fine-tuned model on specialised OSes but it's trivial to give it an .agents dir or readme file that says "to achieve X run Y command" and they are very good, in my experience, at picking that up.

For example, I frequently use Taskfile.yml for running tasks, I dislike Makefiles as they're very linux specific and difficult to read sometimes. This hasn't ever been a problem for Claude even though Taskfile is a relatively niche tool compared to the decades of presence Makefiles have in repositories and on much of the technical internet these models were likely trained on.

Ultimately, cross platform isn't an LLM problem at all, it's just a product decision and I'm looking forward to when the team make the adjustments needed for a cross platform release.

[ant-kurt]

We recently added support for native Windows. Going to close this issue out - please open a new one if you run into any problems! See https://docs.anthropic.com/en/docs/claude-code/setup#windows-setup.

[github-actions[bot]]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.