# WSL oder natives Windows für Coding-Agenten? URL: https://agentvera.dev/de/blog/wsl-vs-native-windows-coding-agents/ · Veröffentlicht: 2026-11-01 Claude Code und Codex in WSL 2 oder nativ unter Windows? Tempo, Sandbox, tmux, CRLF, das langsame /mnt/c und welche Variante für welches Projekt die richtige ist. **Kurz gesagt:** - Liegt dein Code auf dem Laufwerk C: und ist das Projekt Windows-spezifisch (.NET, Unity, Desktop-App), ist natives Windows einfacher und schneller. - WSL 2 ist besser für Projekte, die auf Linux-Tools setzen, für Docker-lastige Arbeit und für die Sandbox von Claude Code; der Code muss dann im Linux-Dateisystem liegen, /mnt/c ist deutlich langsamer. - Beides zu mischen ist möglich; dasselbe Repo von beiden Seiten aus zu bearbeiten führt aber zu Problemen mit Zeilenenden (CRLF) und Dateirechten. Die erste Entscheidung, wenn du unter Windows einen Coding-Agenten einrichtest: WSL oder natives Windows? Vor einem Jahr lautete die Antwort fast immer WSL, weil die meisten Agenten unter Windows nicht sauber liefen. Heute laufen Claude Code, Codex, Gemini CLI und Copilot CLI nativ in PowerShell; die Antwort hängt jetzt vom Projekt ab. ## Die kurze Antwort | Situation | Empfehlung | |---|---| | .NET, C#, Unity, Windows-Desktop-App | Natives Windows | | Code liegt auf `C:`, dein Editor läuft unter Windows | Natives Windows | | Linux-spezifische Tools, Shell-Skripte, Makefiles | WSL 2 | | Docker-lastige Entwicklung | WSL 2 | | Du willst die Sandbox von Claude Code | WSL 2 | | Du willst ein Tool nutzen, das auf tmux aufbaut | WSL 2 | | Firmenrechner, WSL verboten | Natives Windows | ## Was für natives Windows spricht **Kurze Einrichtung.** Claude Code installierst du mit einem PowerShell-Einzeiler, Codex und Gemini CLI per npm. Alle Befehle stehen im Beitrag [Coding-Agenten unter Windows installieren](/de/blog/install-coding-agents-on-windows/). **Schneller Dateizugriff.** Der Code liegt auf `C:`, der Agent läuft unter Windows; keine Dateisystem-Brücke dazwischen. **Windows-Toolchain.** `dotnet`, MSBuild, die Visual-Studio-Compiler und Windows-spezifische SDKs sind direkt erreichbar. Aus WSL heraus lassen sie sich zwar aufrufen, aber nur umständlich. **Die Windows-Sandbox von Codex.** Codex läuft unter nativem Windows mit eigener Sandbox. ## Was gegen natives Windows spricht **Keine Sandbox für Claude Code.** Die Dateisystem- und Netzwerkisolation von Claude Code wird unter nativem Windows nicht unterstützt, in WSL 2 schon. Stattdessen arbeitest du mit [Berechtigungsregeln](/de/blog/claude-code-skip-permissions/). **Kein tmux.** tmux hat keine native Windows-Version. Tools, die auf tmux aufbauen (etwa Claude Squad), laufen unter nativem Windows nicht. **Shell-Unterschiede.** Die meisten Agenten sind darauf trainiert, Bash-Befehle zu erzeugen. Claude Code nutzt Git Bash, wenn Git for Windows installiert ist, sonst PowerShell; andere Agenten nutzen womöglich PowerShell oder `cmd.exe`. Bash-Gewohnheiten wie `rm -rf`, `export` oder `&&` verhalten sich in PowerShell anders. **Probleme mit Pfaden und Zeilenenden.** Pfade mit Backslash, die 260-Zeichen-Grenze und CRLF-Zeilenenden bringen Bearbeitungswerkzeuge ab und zu durcheinander. Die Einstellungen weiter unten lösen das meiste davon. ## Was für WSL 2 spricht **Echtes Linux.** Die Bash-Befehle, die Agenten erzeugen, laufen so, wie sie sind; `make`, `grep`, `sed` und Linux-Pakete sind sofort da. **Sandbox für Claude Code.** In WSL 2 funktioniert die Isolation von Claude Code; du kannst mit weniger Freigaben sicherer arbeiten. **tmux und Terminal-Tools.** tmux, Claude Squad und ähnliche Tools laufen in WSL einfach so. ## Was gegen WSL 2 spricht **`/mnt/c` ist langsam.** Der Zugriff aus WSL 2 auf Windows-Dateien ist deutlich langsamer als auf Dateien im Linux-Dateisystem. Auch Microsofts [eigene Doku](https://learn.microsoft.com/de-de/windows/wsl/filesystems) empfiehlt, Projekte auf der Linux-Seite zu halten. Klone das Repo unter `~/` und öffne es aus dem Windows-Editor über den Pfad `\\wsl$\`. **Zwei getrennte Umgebungen.** Node, Python, git-Anmeldedaten und Agenten-Logins sind auf beiden Seiten getrennt. Womöglich musst du dich bei einem Agenten einmal in WSL und einmal unter Windows anmelden. **Arbeitsspeicher.** Die WSL-2-VM braucht RAM; laufen mehrere Agenten und ein Docker-Stack gleichzeitig, musst du womöglich per `.wslconfig` ein Limit setzen. ## Mischen: dasselbe Repo von beiden Seiten Der häufigste Fehler: das Repo unter Windows halten und einen Agenten aus WSL, einen anderen aus Windows starten. Das Ergebnis: Der eine schreibt Dateien mit LF, der andere mit CRLF; Diffs werden unübersichtlich, manche Bearbeitungswerkzeuge melden „Text nicht gefunden“, und Dateirechte scheinen sich geändert zu haben. Wenn du beide Umgebungen zusammen nutzt: - Halte jedes Repo **auf einer einzigen Seite** und starte die Agenten für dieses Repo von derselben Seite aus. - Füge dem Repo eine `.gitattributes` hinzu: ```gitattributes * text=auto *.sh text eol=lf *.bat text eol=crlf *.ps1 text eol=crlf ``` - Setze auf der Windows-Seite `git config --global core.autocrlf false` und `git config --global core.longpaths true`; die Zeilenenden soll `.gitattributes` regeln. ## Parallele Agenten: auf beiden Seiten möglich Um mehrere Agenten gleichzeitig auszuführen, nutzt du auf beiden Seiten getrennte Git-Worktrees. - **In WSL** gibt es tmux und darauf aufbauende Tools wie Claude Squad. - **Unter nativem Windows** Bereiche im Windows Terminal oder eine Desktop-App, die die Agenten in einem Raster zeigt. AgentVera läuft nativ unter Windows; es öffnet 18 Agenten nebeneinander pro Projekt und bündelt Freigaben in einer einzigen Warteschlange. Agenten in WSL verwaltet es nicht direkt; du kannst sie in einem Terminal-Agenten mit einem Befehl wie `wsl claude` öffnen. Mehr dazu im Guide [Coding-Agenten unter Windows verwalten](/de/blog/coding-agents-on-windows/), die Zusammenfassung findest du auf der [Windows-Seite](/de/windows/). ## Fazit Startest du ein neues Projekt, das nicht an Windows gebunden ist, ist WSL 2 immer noch die Option mit den wenigsten Überraschungen. Liegt dein Code schon unter Windows, läuft dein Editor unter Windows oder setzt das Projekt auf die Windows-Toolchain, reicht natives Windows inzwischen völlig; es gibt keinen Grund mehr, die Agenten nach WSL umzuziehen. Egal was du wählst: Halte ein Repo auf einer einzigen Seite. ## Häufige Fragen **Sollte ich Claude Code in WSL oder nativ unter Windows ausführen?** Nativ unter Windows, wenn dein Projekt Windows-spezifisch ist und dein Code auf dem Laufwerk C: liegt. WSL 2, wenn dein Projekt auf Linux-Tools setzt oder du die Sandbox von Claude Code nutzen willst. Unter nativem Windows gibt es die Sandbox nicht. **Warum ist ein Coding-Agent in WSL langsam?** Wahrscheinlich liegt dein Code unter /mnt/c, also im Windows-Dateisystem. Der Zugriff aus WSL 2 auf Windows-Dateien ist deutlich langsamer als auf Dateien im Linux-Dateisystem. Klone das Repo unter ~/. **Läuft tmux unter Windows?** Nicht nativ; nur in WSL, Cygwin oder MSYS2. Tools wie Claude Squad, die auf tmux aufbauen, brauchen unter Windows deshalb WSL. Unter nativem Windows kannst du Bereiche im Windows Terminal oder einen Agenten-Manager nutzen. **Kann AgentVera Agenten in WSL verwalten?** Nicht direkt. AgentVera läuft nativ unter Windows und startet Agenten, die unter Windows installiert sind. Einen Agenten in WSL kannst du in einem Terminal-Agenten mit einem Befehl wie wsl claude starten; dann bekommst du ein Terminal-Pane, aber keine agentenspezifischen Funktionen wie die Session-Fortsetzung. --- **Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/