Claude Code unter Windows: 7 Fallen aus 1.585 Sitzungen

Veröffentlicht: 08.10.2026 · Lesezeit: 8 Minuten · Kategorie: KI im Betrieb

Die Installation ist der leichte Teil

Claude Code installieren Sie unter Windows in fünf Minuten. Die Anleitung steht auf unserer Seite Claude Code installieren. Die Schwierigkeiten kommen später, wenn der Agent jeden Tag Skripte schreibt, Dateien ablegt und Aufgaben startet.

Wir arbeiten seit April 2026 mit Claude Code auf einem Laptop mit Windows 11. Das Protokollverzeichnis zählt bis heute 1.585 Sitzungen. Jeden Fehler, der uns dabei Daten oder Zeit gekostet hat, haben wir mit Datum und Messwert notiert. Aus diesen Notizen stammen die sieben Fallen unten. Die meisten melden keinen Fehler, den man sofort sieht.

Vor dem Start: nativ oder WSL

Anthropic beschreibt in der Dokumentation zwei Wege. Wir haben die Angaben am 6. Oktober 2026 auf code.claude.com/docs/en/setup abgerufen:

Mit Git for Windows führt Claude Code Befehle in Git Bash aus, ohne Git in PowerShell. Administratorrechte brauchen Sie weder für die Installation noch für den Betrieb, egal welchen Weg Sie wählen.

Wir arbeiten nativ, weil unsere Werkzeuge Windows-Programme sind. Der Preis dafür: Claude Code bewegt sich zwischen zwei Welten. Die Befehle laufen in Git Bash, einer kleinen Linux-Umgebung, die Skripte des Agenten dagegen im Windows-Python. Die ersten beiden Fallen entstehen an dieser Grenze.

Falle 1: Zwei Ordner heißen /tmp

Git Bash legt /tmp unter C:\Users\<Name>\AppData\Local\Temp ab. Windows-Python liest /tmp als C:\tmp. Schreibt ein Bash-Befehl eine Datei nach /tmp und ein Python-Skript liest sie dort, liest es eine andere Datei. Liegt dort zufällig eine alte Datei mit gleichem Namen, gibt es keine Fehlermeldung, nur ein falsches Ergebnis.

Am 10. September 2026 meldete eine unserer Prüfungen deshalb, zwei fremde Firmenwebsites würden unser eigenes Impressum ausliefern. Python hatte eine Datei aus einer früheren Aufgabe gelesen. Beinahe wäre ein Brief mit diesem Befund an die beiden Firmen gegangen. Am 6. Oktober ist uns derselbe Fehler noch einmal passiert.

Abhilfe: Abruf und Auswertung im selben Programm erledigen, oder auf beiden Seiten absolute Pfade wie C:/tmp/datei.html schreiben. Bei uns steht das als feste Regel in den Anweisungen an Claude.

Falle 2: Backslashes verschwinden

Windows-Pfade enthalten Backslashes, und Bash liest einen Backslash ohne Anführungszeichen als Escape-Zeichen. Auf echo C:\Users\Name\tools antwortet Git Bash mit C:UsersNametools. Wir haben das für diesen Beitrag am 6. Oktober nachgestellt.

Claude Code übernimmt Windows-Pfade oft unverändert in Bash-Befehle. Ein Überwachungsskript für die Nachrichten zwischen unseren Agenten fand auf diese Weise seine eigene Datei nicht.

Abhilfe: In Bash-Befehlen Schrägstriche verwenden (C:/Users/... oder /c/Users/...) oder den Pfad in Anführungszeichen setzen. Diese Regel gehört in die CLAUDE.md Ihres Projekts. Das ist die Datei mit Anweisungen, die Claude Code bei jedem Start liest.

Falle 3: Speichern scheitert, solange jemand liest

Ein verbreitetes Muster für sicheres Speichern geht so: erst eine Zwischendatei schreiben, dann mit os.replace über das Original schieben. Unter Linux funktioniert das, und auch unser Code war so gebaut. Unter Windows scheitert das Umbenennen mit „Zugriff verweigert“ (WinError 5), solange ein anderes Programm die Zieldatei geöffnet hat.

Unsere gemeinsame Aufgabenliste lesen mehrere Agenten und eine Übersichtsseite alle paar Sekunden. Vom 30. September, 16 Uhr, bis zum 1. Oktober, 13 Uhr, gingen dadurch 51 Speichervorgänge verloren. Gezählt haben wir sie an den verwaisten Zwischendateien neben der Liste. Für die Agenten sah es aus, als hätte niemand die Aufgaben erledigt.

Abhilfe: Das Umbenennen einige Sekunden lang wiederholen und danach direkt in die Datei schreiben. Sicher ist der direkte Weg nur, wenn jedes Programm, das die Datei schreibt, dieselbe Sperre hält. Am 6. Oktober fanden wir zwei Schreiber ohne Sperre. Im Nachstellen beschädigten zwei gleichzeitige Schreibvorgänge die Datei in 14 von 40 Läufen. Suchen Sie deshalb alle Stellen, die eine geteilte Datei schreiben, nicht nur das Hauptskript.

Falle 4: Die Aufgabenplanung bremst Ihre Dienste

Was der Agent nachts oder alle 15 Minuten tun soll, landet unter Windows meist in der Aufgabenplanung. Die startet Aufgaben standardmäßig mit Priorität 7. Das heißt Rechenzeit unter normal und niedriger Vorrang beim Zugriff auf Platte und Speicher.

Auf unserem Laptop beantwortet ein kleiner Dienst Abfragen an die Google Search Console. Aus der Aufgabenplanung gestartet brauchte er am 2. Oktober 60 bis 170 Sekunden je Antwort, manchmal kam gar keine. Im Konsolenfenster brauchte derselbe Code 0,3 bis 1,5 Sekunden. Nach dem Umstellen auf Priorität 4 lag die Antwortzeit bei 0,35 bis 0,7 Sekunden.

Abhilfe: Bei jedem Dienst, auf den andere Programme warten, die Priorität prüfen, etwa mit (Get-ScheduledTask "Name").Settings.Priority. Das Netz verdächtigen Sie erst danach.

Falle 5: Python-Fenster stehlen den Fokus

26 geplante Aufgaben starteten bei uns python.exe oder cmd.exe mit sichtbarem Fenster. Jedes neue Fenster nahm dem Menschen am Laptop den Fokus, auch mitten im Satz. Am 5. Oktober haben wir alle 26 umgestellt.

Abhilfe: Die Aufgabe über conhost.exe --headless starten und das eigentliche Programm als Argument übergeben. Bei uns laufen die Programme seitdem ohne Fenster, Ausgaben und Umleitungen in Dateien funktionieren weiter. pythonw.exe haben wir verworfen: Dort gibt es keine Standardausgabe, und Skripte, die darauf zugreifen, brechen ab.

Falle 6: Nach dem Stromausfall ist die Datei voller Nullen

Am 2. Oktober fiel bei uns der Strom aus, und irgendwann ging auch der Laptop aus. Ein Textentwurf, zwei Minuten vorher gespeichert, hatte danach die richtige Größe von 11.654 Bytes und bestand nur aus Null-Bytes. Die automatische Sicherungskopie ebenso. Windows hatte die Dateigröße schon eingetragen, den Inhalt aber nicht mehr auf die Platte geschrieben.

Aufgefallen ist es, weil unser Textprüfer „1 Wort“ zählte und trotzdem keinen Fehler meldete. Hätte ein Skript die Datei ungeprüft hochgeladen, stünde eine leere Seite online.

Abhilfe: Nach jedem Stromausfall oder Absturz die Dateien der letzten Stunde auf Null-Bytes prüfen. Wir haben an dem Tag 446 Dateien geprüft und eine betroffene gefunden. Unsere Skripte, die etwas veröffentlichen, prüfen seitdem vorher auf Null-Bytes und eine Mindestlänge.

Falle 7: Git verbucht gesperrte Ordner als gelöscht

Wer neben Claude Code auch Codex von OpenAI betreibt, sollte diese Falle kennen. Codex führt Befehle unter Windows in einer Sandbox mit eigenen Benutzerkonten aus. Einige Ordner, die dort entstanden, konnte unser normales Konto nicht lesen. Git meldet dazu nur warning: could not open directory und behandelt die Dateien darin als gelöscht.

Am 4. Oktober zeigte eine unserer Sicherungen deshalb 425.734 gelöschte Zeilen. Auf der Platte lag alles noch. Gefährlich ist das in beide Richtungen: Eine solche Zahl sieht aus wie Datenverlust, und wer sie als Rauschen abtut, übersieht beim nächsten Mal einen echten.

Abhilfe: Nach jeder Sicherung die Löschungen je Datei ansehen (git show --numstat --format= HEAD) und Warnungen vor dem Commit lesen.

Wo unsere Zahlen nicht tragen

Alle Messwerte stammen von einem einzigen Laptop mit Windows 11 Home und aus unserer Arbeitsweise: viele Agenten parallel, viele geplante Aufgaben, Dateien, die mehrere Programme gleichzeitig lesen. Wer Claude Code allein in einem Projekt nutzt, trifft die Fallen 3 bis 5 wahrscheinlich nie.

Unter WSL 2 haben wir nicht gemessen. Die 1.585 Sitzungen sind gezählte Protokolldateien. Wie viele davon kurz waren oder abbrachen, haben wir nicht ausgewertet.

Was Sie heute tun können

1. Schreiben Sie zwei Zeilen in die CLAUDE.md Ihres Projekts: Pfade in Bash mit Schrägstrichen, und Bash und Python teilen sich keinen /tmp.
2. Prüfen Sie die Priorität jeder geplanten Aufgabe, auf die ein anderes Programm wartet.
3. Bauen Sie Ihre Prüfskripte so, dass eine leere oder winzige Datei Alarm auslöst, statt als „keine Befunde“ durchzugehen.

Brauchen Sie Sandbox-Schutz für die Befehle des Agenten, nehmen Sie WSL 2 statt der nativen Installation.

Sie wollen Claude Code im Team unter Windows einführen? Im Claude Code Coaching richten wir die Anweisungsdateien und geplanten Aufgaben mit Ihnen ein. Wie wir solche Einführungen aufbauen, steht auf der Seite Claude Code Setup.