[Request] Windows native support

[ladyada]

I'm sure its on your TODO list but perhaps an issue is useful so other people can subscribe to it :)

We're using Claude code to do a lot of hardware / firmware development and WSL is terrible about USB interfacing due to the devices re-enumerating. so stuff like automating debugging/programming of hardware that connects USB is not always possible with USBIPD.

thank you 🙏

[eabase]

Indeed WSL is the absolute worst of all worlds. Even Cygwin, MSYS/MINGW64 or VirtualBox with a nix VM is a far better option.

[vec715]

is there any ETA when claude code will be available on windows? since not all projects can support WSL, especially things like C# project which are intended to run on windows natively and there is no point to setup WSL

[JakobBruenker]

Shouldn't Claude be able to run Windows commands from within WSL if you instruct it to do so, since you can call .exe's in WSL? It seems like that would be a workaround for this issue.

[NathanSweet]

You can easily make it run on Cygwin:

1. Run npm view @anthropic-ai/claude-code to get the tarball URL. Decompress it.
2. Don't bother trying to npm install. Look in cli.js to see the command at the top, run it: node --no-warnings --enable-source-maps cli.js
3. It works, but will complain about No suitable shell found. Edit cli.js, find that text, add &&false to the if before it.
4. Enjoy. I found mkdir fails, despite being on both the CMD and Cygwin path. I created dirs manually. Claude is able to create text files just fine, which is most of what you need, at least when generating new source files. I haven't tried editing files. Even on Linux it does a terrible job finding replacement strings, resorts to sed, binary, etc so that may be a showstopper on Cygwin.

I expected it wouldn't take a huge amount of effort to make it work properly with Cygwin, but there's no way I'll punish myself with node so hopefully others can do it.

EDIT: Updating files works just fine. It has done everything I wanted it to do: creating new code and refactoring that code. The only thing it truly failed on was mkdir. It doesn't seem very far from getting it to work on Windows, even if there are caveats like missing CLI utilities (if only because they aren't installed in Cygwin).

Anyway, a better idea is to install a Debian VM without a desktop in Virtual Box running headless, then connect to it using PuTTy. Mount your project folders so you can work on your files directly. When running headless, Virtual Box can be closed and no VM window is shown.

[olliejm]

Just a +1 for native windows support. I prefer developing on macOS or Linux, but have to use Windows a lot for various reasons, and honestly I just don't like WSL subjectively (and I believe there's more legitimate issues with it than that also). What I'd really want it for is for Jetbrains Rider, right now it seems the functionality of the official Jetbrains plugin is poor on windows, which makes it hard to justify paying for Claude Pro over using their own Junie, which would function the same on any OS I happen to be using

[gunpal5]

Its really inconvenient to use with WSL. it keeps freezing my Ubuntu WSL instance. We need Native Windows Support. if that's not possible. then please allow us to use the Max Plan with third party coding agents like Roo Code.

[vec715]

actually, I gave another shot to WSL and honestly it works pretty fine. it consume around 400mb for my nixos instance and I'm using it mainly for Claude code only, windows filesystem already mounted so this is very easy to give Claude access to windows local projects. the only issue with .net project right now, it require specific windows dependencies so I'm forced to validate the results manually instead of let Claude to run.

[excpt]

I am Windows developer as well. Support for native access to msbuild and dotnet for desktop apps is impossible with WSL. Always validating every little step by hand is not helpful. Please put native Windows support on your roadmap.

[excpt]

Workaround that works for me - in a Ubuntu wsl machine:

echo 'export PATH="$PATH:/mnt/c/Program Files/dotnet"' >> ~/.bashrc
echo 'alias dotnet='dotnet.exe' >> ~/.bashrc
source ~/.bashrc

$ dotnet --list-sdks
5.0.408 [C:\Program Files\dotnet\sdk]
6.0.428 [C:\Program Files\dotnet\sdk]
8.0.411 [C:\Program Files\dotnet\sdk]
9.0.204 [C:\Program Files\dotnet\sdk]

[GradeSchool]

Claude code is a "world class" product. It should run in windows without WSL. It "works" in WSL but creates almost as many problems as it solves.

[dustinehagen]

claude code in windows please please please please!

[SeungHyun-Hwang]

While simple program development is possible with WSL, it is very cumbersome to change related settings in WSL when using source management systems such as Perforce or calling Windows-specific tools with prebuild events. Please provide native support!

[Raymonf]

I got it sorta working in MSYS2 MINGW64. Here's a brief outline of what I did:

1. pacman -Syu git mingw-w64-x86_64-nodejs mingw-w64-x86_64-ripgrep
2. get the tgz of the extension and extract
3. empty out scripts/preinstall.js to remove the platform check
4. edit cli.js, find and replace .tmpdir() -> .tmpdir().replace(/^[A-Za-z]:/, s => `/${s[0].toLowerCase()}`).replace(/\\/g, '/')
5. repack the extension
6. npm install -g repacked.tgz

It seems to mostly work, though some commands are not happy because the directory separator character \ is sometimes interpreted as an escape character.

edit: oh right, ls sometimes doesn't work because it thinks /c/whatever is not the same as the current directory C:\whatever but that hasn't been an issue so far?

[dustinehagen]

I got it sorta working in MSYS2 MINGW64. Here's a brief outline of what I did:

1. pacman -Syu git mingw-w64-x86_64-nodejs mingw-w64-x86_64-ripgrep
2. get the tgz of the extension and extract
3. empty out scripts/preinstall.js to remove the platform check
4. edit cli.js, find and replace .tmpdir() -> .tmpdir().replace(/^[A-Za-z]:/, s => `/${s[0].toLowerCase()}`).replace(/\\/g, '/')
5. repack the extension
6. npm install -g repacked.tgz

It seems to mostly work, though some commands are not happy because the directory separator character \ is sometimes interpreted as an escape character.

edit: oh right, ls sometimes doesn't work because it thinks /c/whatever is not the same as the current directory C:\whatever but that hasn't been an issue so far?

sick dude. keep up the awesome work!

[rhm]

Adding my support for a native Windows version. I'm running under WSL2 at the moment and it's amazing with Linux code. But although WSL2 enables transparent filesystem access between Windows and Linux worlds, it's far from ideal. Integration with Visual Studio would be highly desired too (VSCode kinda sucks for C++ development by comparison). I would get my whole company using CC if it would run natively on windows as it's so much better than Github Copilot. But we need to work with C++ in Visual Studio on Windows.

[iSplasher]

In MSYS2 environments, one can do:

1. npm view @anthropic-ai/claude-code
2. wget <tarball url>
3. tar xf <tarfile>
4. nano ./package/package.json
5. Remove the preinstall key from scripts
6. cd ./package && tar -czf ../claude.tgz ./* && npm install -g ../claude.tgz

[vec715]

So, Gemini CLI can be installed natively on Windows. I’m wondering what limitations prevent Claude from working natively on Windows, or why they can’t be fixed or aren’t even planned. Honestly, I just don’t understand it

[gunpal5]

@vec715 I think its related to Bash commands and how claude code is optimized for bash commands. they probably need to do that kind of optimization for windows terminal.

[matthoneycutt-sm]

There's an awesome wrapper that allows Claude Code to run natively on windows now: https://github.com/somersby10ml/win-claude-code/

It's the fine work of somersby10ml.

[gunpal5]

I found a solution for WSL and windows:

It turns out you can use cmd.exe /c to run windows specific commands e.g. cmd.exe /c dotnet

Simplest: Add aliases for your CLI commands in your bash configuration

Open Bash Configuration: with nano ~/.bashrc

add aliases to your build tools e.g. for dotnet: alias dotnet="cmd.exe /c dotnet"

Ask claude code to update Claude.md to use cmd.exe /c for windows specific commands and it will add instruction into Claude.md to use the specific commands. for example I asked claude code to use cmd.exe /c npm build for my angular frontend.

[eabase]

It turns out you can use cmd.exe /c to run windows specific commands...

For the love of any god, please stop using cmd! At least convert it to Powershell.

[eabase]

There's an awesome wrapper that allows Claude Code to run natively on windows...

Sounds promising, but didn't try yet. Can this be merged into this repo?

[gunpal5]

Anthropic has released Windows support silently, I've been using Claude Code natively on windows since morning. Its lot faster.

[gunpal5]

It turns out you can use cmd.exe /c to run windows specific commands...

For the love of any god, please stop using cmd! At least convert it to Powershell.

That's funny, what's wrong with cmd.exe to execute commands?

[MadSpindel]

Anthropic has released Windows support silently, I've been using Claude Code natively on windows since morning. Its lot faster.

Yeah, I was confused when I tried Claude Code on Windows today and it worked without issues. This looks to be fixed now.

[vec715]

Anthropic has released Windows support silently, I've been using Claude Code natively on windows since morning. Its lot faster.

noooo way, it really works, finally! thank you for letting us know

[vec715]

But I think there are still some issues. It seems that when calling Claude on Windows, it doesn’t remember its path and uses the root directory instead. I might be wrong, but on Linux, if I call Claude from a project subdirectory, it doesn't ask me to accept all risks again the next time I use it. However, on Windows, I see this prompt every time I open claude. Also, when suggesting the project path, it doesn't use a relative directory and instead it shows the full path from the root. I also suspect it might not respect the local CLAUDE.md file because of this, but I'm not completely sure

[gunpal5]

even it has some windows issue. I managed to get more work done with it in last 2 days, than I was able to with WSL version.

[fatihaziz]

Anthropic has released Windows support silently, I've been using Claude Code natively on windows since morning. Its lot faster.

how? i still cannot use it today. getting error Posix shell when try to run claude

[vec715]

Anthropic has released Windows support silently, I've been using Claude Code natively on windows since morning. Its lot faster.

how? i still cannot use it today. getting error Posix shell when try to run claude

probably you just need to install/update the latest version