Zurück

•22 Min. Lesezeit

Wenn Claude Code kein Deutsch kann

Über einen hartnäckigen Clipboard-Bug, eine abgeschottete WSL2, und acht Zeilen Bash als elegante Mogelpackung für ein reales Problem

Seit diesem Jahr bin ich ein Claude Code Power User: Ich arbeite täglich intensiv mit dem Tool im integrierten Terminal von VS Code. Links die Dateien, in der Mitte Code und Tabs, unten Claude. Ich entwickle auf Deutsch, ich bekomme Antworten auf Deutsch, und ich führe echte Gespräche mit dem Tool — nicht nur "schreib mir eine Funktion", sondern Diskussionen über Architektur, Abwägungen, Alternativen.

Ein zentraler Teil dieses Workflows: Ich kopiere Sätze aus Claudes Antworten in die Eingabezeile, um sie zu kommentieren, zu hinterfragen, zu referenzieren. Ich markiere einen Absatz mit der Maus, Rechtsklick, Einfügen — und baue darauf auf. Manchmal kopiere ich auch längere Absätze in eine andere Datei, um später darauf zurückzugreifen. Das ist keine Kleinigkeit am Rande meines Workflows.
Es ist ein Kernbestandteil davon.

Und genau das funktionierte plötzlich nicht mehr.

Ausgenommen auf meiner alten Debian-Distro mit der alten Claude-Code-Version — dort lief alles wie gehabt. Aber auf meiner frisch aufgesetzten neuen Distro mit der aktuellsten Claude-Code-Version (über den claude-eigenen Installer): kaputt . Beide Distros waren isoliert. Beide hatten dieselbe WSL-Konfiguration. Der Unterschied war: neue Distro, neue Version. Und das Ergebnis war das: 

ð¥ Neues aus der verrückten Hölle der Zeichensätze! ð¤¯

Statt 🔥 Neues aus der verrückten Hölle der Zeichensätze! 🤯1. Das hat mich — ich sage es offen — sofort in den Wahnsinn getrieben!

TL;DR — Du kennst das Problem und willst nur den Fix?

Voraussetzung: WSL2, Windows 11, abgeschottete Distro ( interop enabled = false).

sudo apt install wl-clipboard
sudo tee /usr/local/bin/powershell.exe << 'EOF'
#!/bin/bash
if [[ "$*" == *"Set-Clipboard"* ]]; then cat | wl-copy
elif [[ "$*" == *"Get-Clipboard"* ]]; then wl-paste --no-newline
fi
EOF
sudo chmod +x /usr/local/bin/powershell.exe

→ Vollständige Anleitung im Appendix

Wer das Muster kennt, weiß sofort was es ist: UTF-8-Bytes, die als Latin-1 gelesen werden. ä ist die Latin-1-Darstellung der beiden UTF-8-Bytes 0xC3 0xA4, die zusammen das ä ergeben. Jemand irgendwo in der Kette liest UTF-8, als wäre es Latin-1. Klassischer Encoding-Fehler, Brot-und-Butter-Problem. Aber wo genau?

Die erste Stunde: Verdächtige ohne Motiv

VS Code war der naheliegende erste Verdächtige. Das integrierte Terminal, die WSL-Extension, irgendeine Encoding-Einstellung, die ich übersehen hatte. Ich verbrachte eine gute Stunde damit, alle üblichen Kandidaten abzuhaken.

settings.json: terminal.integrated.defaultEncoding, files.encoding, terminal.integrated.env.linux mit explizitem LANG=de_DE.UTF-8. Alles gesetzt, alles neu gestartet, kein Effekt.

Locales auf der frisch aufgesetzten Debian-Distro: dpkg-reconfigure locales, locale-gen de_DE.UTF-8, update-locale. ~/.bashrc und ~/.inputrc geprüft und angepasst.

locale
# LANG=de_DE.UTF-8
# LC_CTYPE="de_DE.UTF-8"
# LC_ALL=de_DE.UTF-8
# ... alles korrekt

Und dann der entscheidende Test, der VS Code aus dem Spiel nahm: dieselbe lokale VS Code-Instanz, dieselbe Konfiguration, dieselbe Vorgehensweise — aber verbunden mit meiner alten Debian-Distro, auf der eine ältere Claude-Code-Version lief. Kein Bug. Alles korrekt.

VS Code ist konstant. Der Bug ist es nicht. Also liegt es an Claude Code.

Das war der Moment, wo es interessant wurde.

Was das Terminal weiß — und was Claude Code davon hält

Ein paar schnelle Tests zeigten: Das Terminal selbst hat kein Encoding-Problem.

echo "🔥 Neues aus der verrückten Hölle der Zeichensätze! 🤯"
# → 🔥 Neues aus der verrückten Hölle der Zeichensätze! 🤯 ✓

printf '\xc3\xa4\xc3\xb6\xc3\xbc\n'
# → äöü ✓

UTF-8 funktioniert einwandfrei in der Shell. Das Problem liegt spezifisch in Claude Code — und nach etwas genauerer Beobachtung noch spezifischer: nicht beim Tippen, nicht beim Anzeigen, nicht beim Einfügen von außen. Nur beim Kopieren innerhalb der Claude-Code-TUI und anschließendem Einfügen.

Claude Code hat, wie sich herausstellt, einen eigenen internen Clipboard-Mechanismus. Wenn man Text in der TUI markiert und kopiert, erscheint die Meldung "copied n chars to clipboard" — Claude Code verwaltet den Clipboard-Inhalt selbst, geht nicht einfach durch den Terminal-Layer. Und genau dieser Mechanismus war kaputt.

Umgebungsvariablen halfen nicht:

LANG=de_DE.UTF-8 LC_ALL=de_DE.UTF-8 claude
TERM=xterm claude
TERM=linux claude
# → alles ohne Effekt

Warum mein Setup den Bug sichtbar macht

Bevor ich ins Binary schaue, ein wichtiger Kontext — denn ohne ihn ergibt der Rest keinen Sinn.

Ich entwickle in einer abgeschotteten WSL2-Umgebung. "Abgeschottet" bedeutet in meinem Fall drei Zeilen in der /etc/wsl.conf:

[interop]
enabled = false
appendWindowsPath = false

Diese drei Zeilen sorgen dafür, dass meine WSL2-Instanz Windows nicht kennt. Kein /mnt/c . Kein Windows-PATH. Keine Windows-Binaries, die aus Linux heraus aufgerufen werden können. Die WSL läuft als geschlossene Welt — was darin passiert, bleibt darin. Genauer gesagt: Windows-Binaries und der Windows-PATH bleiben draußen. Netzwerkzugriff hat die WSL weiterhin — das ist für Entwicklungsarbeit schlicht notwendig.

Warum? Weil bun install kein Recht hat, meine SSH-Schlüssel zu lesen. Weil eine kompromittierte Abhängigkeit in einem Testprojekt keinen Zugriff auf meine Windows-Benutzerdaten haben soll. Das ist eine bewusste Entscheidung, keine Vergesslichkeit.

Die Konsequenz: powershell.exe liegt nicht im PATH. Wenn Claude Code versucht, powershell.exe aufzurufen, findet es ... nichts.

Mit diesem Kontext im Hinterkopf — zurück zum Binary.

Der Blick ins Binary: Detektivarbeit mit Bordmitteln

Hier wurde es richtig spannend — und hier musste ich einen Umweg nehmen, der sich als der eigentlich aufschlussreiche Weg herausstellte.

Claude Code ist proprietär — es gibt kein GitHub-Repository in das man einfach reinschauen könnte, kein git log , das die Implementierungsdetails offenbart, keine öffentliche Codebasis. Was Anthropic intern plant und wie es Entscheidungen trifft, bleibt Anthropics Sache.

Was man bekommt, ist allerdings ein interessantes Binary. Claude Code ist eine Bun Standalone Executable : Bun kompiliert JavaScript-Code nicht wirklich in Maschinencode, sondern bettet das komplette JavaScript-Bundle als Daten direkt ein. Der Bun-Runtime-Teil des Binaries entpackt und führt dieses Bundle beim Start aus. Konsequenz: Der gesamte "Quellcode" von Claude Code steckt als lesbarer Text im Binary — eingefroren, aber faktisch einsehbar. Proprietär, aber unverschlüsselt. Security through obscurity gibt es hier nicht — Bun hebelt es durch sein eigenes Packaging-Konzept aus.

Das kann man mit einem einfachen Blick bestätigen:

head -3 ~/.local/share/claude/versions/2.1.162
# ELF>... → natives Binary, kein Script

ELF — das ist das Format nativer Linux-Binaries. Kein Shebang, kein #!/usr/bin/env node , kein lesbarer JavaScript-Anfang. Das erklärt auch warum die Umgebungsvariablen nichts bewirkten — nicht, weil ein ELF-Binary grundsätzlich keine LANG -Variable liest (das tun native Binaries durchaus, sofern sie glibc nutzen), sondern weil die Bun-Runtime oder das interne Clipboard-Modul von Claude Code diese Variable für diesen spezifischen Codepath schlicht ignoriert. Der Clipboard-Mechanismus schaltet intern auf Windows/WSL-Erkennung — und das passiert unabhängig von Locale-Einstellungen.

Aber weil das Bundle eingebettet ist, lässt sich trotzdem hineinsehen. Normalerweise würde man strings benutzen, um lesbare Texte aus einem Binary zu extrahieren. Auf meiner frischen Distro war es nicht installiert: 

strings ~/.local/share/claude/versions/2.1.162
# bash: command not found: strings

Kein Problem. tr und grep sind immer da:

cat ~/.local/share/claude/versions/2.1.162 | tr -cd '[:print:]\n' | \
  grep -i "clipboard\|powershell\|Set-Clipboard" | head -20

Ich hatte zu diesem Zeitpunkt bereits eine Vermutung, wohin die Suche führt — denn der CHANGELOG von Claude Code 2.1.70 war eindeutig: 

Fixed clipboard corrupting non-ASCII text (CJK, emoji) on Windows/WSL 
by using PowerShell Set-Clipboard

PowerShell also. Aber wie genau ? Das steht im CHANGELOG nicht. Und genau das wollte ich wissen — denn ohne die genauen Befehle zu kennen, kann man keinen Ersatz bauen.

Was dann aus dem Binary kam, war zunächst überwältigend: mehrere Megabyte eingebetteten JavaScript-Codes, komplett mit Kommentaren, Variablennamen, String-Literalen — der gesamte Quellcode von Claude Code, ungefiltert durch ein Terminal gejagt. UI-Strings, interne Fehlermeldungen, HTTP-Header, WebAssembly-Typen, CSS-Klassen, interne Konstanten. Das Binary von Claude Code ist ein kleines Universum.

Aber inmitten dieses Rauschens — zwei Zeilen, die alles präzisierten:

[Console]::InputEncoding = [Text.Encoding]::UTF8; Set-Clipboard -Value ([Console]::In.ReadToEnd())
[Console]::OutputEncoding = [Text.Encoding]::UTF8; Get-Clipboard -Raw

Das sind die exakten PowerShell-Befehle. Mit explizitem UTF-8-Encoding. Direkt ins Binary eingebettet. Nirgendwo in der offiziellen Dokumentation erwähnt — nur hier, im eingebetteten Bundle, wenn man weiß wo man suchen muss.

Das ist der Moment, wo sich alles vollständig fügte. Claude Code delegiert das Encoding-Problem an PowerShell: es ruft powershell.exe auf, weist PowerShell an [Console]::InputEncoding auf UTF-8 zu setzen, bevor es in die Zwischenablage schreibt, und [Console]::OutputEncoding auf UTF-8 bevor es daraus liest. PowerShell ist der UTF-8-fähige Mittelsmann. Das ist ein eleganter Fix — für alle die powershell.exe im PATH haben.

Warum überhaupt PowerShell?

Eine berechtigte Frage. Claude Code läuft schließlich nicht nur in der WSL — es gibt auch native Linux-Installationen, auf denen powershell.exe nie vorhanden sein wird. Der CHANGELOG und das Binary legen nahe: Der PowerShell-Codepath ist spezifisch für Windows- und WSL-Umgebungen gedacht, wo PowerShell üblicherweise verfügbar ist. Auf nativem Linux greift vermutlich ein anderer Codepath — das Binary enthielt in der Grep-Ausgabe auch Hinweise auf xclip und xsel . Wie genau Claude Code entscheidet, welchen Pfad es nimmt, lässt sich aus dem eingebetteten Bundle zwar prinzipiell herauslesen — aber das war nicht Ziel dieser Debugging-Session. Was ich weiß: In meiner abgeschotteten WSL2 landete es beim PowerShell-Pfad, fand kein powershell.exe — und scheiterte.

Die Welt der Standard-WSL2-Nutzer: alles funktioniert, niemand weiß warum, niemand muss es wissen.

Meine Welt: powershell.exe nicht gefunden — weil meine WSL2 abgeschottet ist und Windows-Binaries schlicht nicht existieren. Fallback. Mojibake.

Damit hatte ich das Problem zwar nicht gelöst — aber seine Ursache vollständig und präzise verstanden. Das ist oft der wertvollere Schritt.

Die Lösung: Alles außer Kompromiss

Ich hätte natürlich Interop aktivieren können. enabled = true, appendWindowsPath = true, /mnt/c gemountet, powershell.exe im PATH — fertig. Drei Minuten Arbeit, Bug weg.

Aber das wäre der falsche Weg gewesen. Jedenfalls für mich. Nicht weil es nicht funktioniert hätte, sondern weil es die Sicherheitsgrenze aufgehoben hätte, die ich bewusst gezogen habe. Einen Bug in einem Werkzeug zu beheben indem man die eigene Sicherheitsarchitektur opfert — das ist kein Fix, das ist Kapitulation!

Also: Was braucht Claude Code? Es braucht powershell.exe im PATH, das zwei spezifische Befehle versteht:

Set-Clipboard -Value (...)   # Text in Clipboard schreiben
Get-Clipboard -Raw           # Text aus Clipboard lesen

Was wenn powershell.exe im PATH liegt — aber gar kein PowerShell ist?

Das ist der Gedanke, der alles veränderte. Und für seine Umsetzung brauchte ich einen Clipboard-Mechanismus, der vollständig innerhalb der WSL2-Sandbox funktioniert — ohne jeden Windows-Zugriff. Genau hier kam eine Entdeckung ins Spiel, die mich selbst überraschte.

WSLg: Der stille Mitspieler

echo $WAYLAND_DISPLAY
# wayland-0

Wayland läuft — obwohl ich keine GUI-Pakete installiert habe, obwohl die Distro frisch aufgesetzt ist, obwohl nirgendwo ein Desktop-Environment konfiguriert ist. Woher kommt das?

WSLg : Windows Subsystem for Linux GUI. Seit Windows 11 ist WSLg fester Bestandteil von WSL2 und startet automatisch mit jeder WSL2-Instanz. Es stellt einen vollständigen Wayland-Compositor und einen X-Server bereit — nicht als optionales Feature, sondern als stille Infrastruktur im Hintergrund. Das $WAYLAND_DISPLAY=wayland-0 kommt von Windows, nicht von Debian. Die Distro erbt es, ohne etwas dafür tun zu müssen.

Das bedeutet: wl-copy und wl-paste aus dem wl-clipboard -Paket können diesen Wayland-Socket direkt nutzen. Kein eigener Compositor, keine X11-Konfiguration, keine weiteren Abhängigkeiten. Einfach installieren und verwenden: 

sudo apt install wl-clipboard

Damit hatte ich alle Zutaten beisammen: einen Clipboard-Mechanismus der vollständig in Linux lebt, und die Erkenntnis, was Claude Code genau erwartet. Zeit für das Script!

Das Script: Acht Zeilen, die alles lösen

Ich möchte kurz innehalten und den Kern des Gedankens explizit machen, bevor ich das Script zeige. Denn er ist — finde ich — von einer kleinen, stillen Eleganz, die sich nicht sofort erschließt.

Claude Code sucht powershell.exe im PATH. Es ruft dieses Binary mit zwei spezifischen Befehlen auf. Es erwartet keine bestimmte PowerShell-Version, keine bestimmte Windows-Integration, keinen bestimmten Ursprung des Binaries. Es erwartet nur: ein Programm namens powershell.exe, das Set-Clipboard und Get-Clipboard versteht.

Was wenn dieses Programm aus acht Zeilen Bash besteht?

Da /usr/local/bin root gehört, brauchen wir sudo tee statt cat > — sonst scheitert das Schreiben mit "Keine Berechtigung":

sudo tee /usr/local/bin/powershell.exe << 'EOF'
#!/bin/bash
if [[ "$*" == *"Set-Clipboard"* ]]; then
    cat | wl-copy
elif [[ "$*" == *"Get-Clipboard"* ]]; then
    wl-paste --no-newline  # LF statt CRLF — Claude Code ist hier tolerant
fi
EOF
sudo chmod +x /usr/local/bin/powershell.exe

Das ist alles. Ein Bash-Script, das auf powershell.exe hört, das die zwei Befehle erkennt, die Claude Code aufruft, und das sie auf wl-copy und wl-paste umleitet. Kein PowerShell. Kein Windows. Keine Interop. Keine Sicherheitsgrenze die auch nur einen Millimeter verschoben wird.

Eine kurze technische Anmerkung zur Robustheit: Das Script matcht mit "$*" — alle übergebenen Argumente als ein String — auf die Substrings Set-Clipboard und Get-Clipboard . Diese exakten Strings haben wir direkt aus dem eingebetteten Bundle extrahiert. Claude Code übergibt sie so, unabhängig von zusätzlichen Flags wie -NoProfile oder -NonInteractive — der Substring-Match greift in jedem Fall. Wir matchen nicht auf die genaue Reihenfolge oder das exakte Quoting, sondern auf das, was Claude Code garantiert mitschickt.

Ein theoretisches Restrisiko bleibt: wl-paste liefert Unix-Zeilenenden (LF), echtes PowerShell auf Windows würde CRLF liefern. In der Praxis ist Claude Code hier tolerant — der Test zeigt kein Problem. Sollte Anthropic das interne Parsing jemals verschärfen, wäre das die einzige Sollbruchstelle.

Claude Code ruft powershell.exe auf — und bekommt Bash. Es weiß es nicht. Es muss es nicht wissen. Die Schnittstelle ist erfüllt, das Ergebnis ist korrekt, alle sind glücklich.

Wer es präzise benennen möchte: Das ist das Unix-Philosophie-Prinzip in Reinform — ein Programm muss nichts über seinen Aufrufer wissen, nur über seine Schnittstelle. Oder, für die objektorientiert denkenden unter uns: Dependency Injection auf Shell-Ebene. Claude Code hat eine Abhängigkeit ( powershell.exe ), wir injizieren unsere eigene Implementierung — und Claude Code merkt es nicht, weil es nur die Schnittstelle kennt, nicht die Implementierung.

Streng genommen ist das kein Duck Typing — Duck Typing beschreibt Typsysteme in dynamischen Programmiersprachen. Aber die Idee ist dieselbe, und ich finde sie zu schön, um sie nicht zu erwähnen: Wenn es läuft wie eine Ente und quakt wie eine Ente, fragt niemand nach dem Ausweis. Claude Code fragt auch nicht. Mein powershell.exe quakt Set-Clipboard und Get-Clipboard — das reicht vollkommen.

Der Test

echo "🔥 Neues aus der verrückten Hölle der Zeichensätze! 🤯" | /usr/local/bin/powershell.exe -Command "Set-Clipboard"
/usr/local/bin/powershell.exe -Command "Get-Clipboard -Raw"
# → 🔥 Neues aus der verrückten Hölle der Zeichensätze! 🤯 ✓

Und in Claude Code: Umlaute tippen, mit der Maus markieren, Rechtsklick → Einfügen:

🔥 Neues aus der verrückten Hölle der Zeichensätze! 🤯

Korrekt. Vollständig. Ohne Kompromiss.

Ich gebe zu: in diesem Moment musste ich ausgiebig — und äußerst zufrieden — grinsen. Nach einer Stunde VS Code-Debugging, nach dem langen Weg durch Locale-Konfiguration, Terminal-Encoding, Binary-Analyse und PowerShell-Codepath-Archäologie — die Lösung sind acht Zeilen Bash. Das ist Softwareentwicklung in ihrer reinsten Form: ein Problem verstehen, eine minimale Lösung finden, fertig. 😉

Die Verifikation: Wirklich noch abgeschottet?

Zur Sicherheit: Drei unabhängige Checks bestätigen, dass die Abschottung vollständig erhalten ist.

# Kernel-Interface: Interop aktiv?
cat /proc/sys/fs/binfmt_misc/WSLInterop
# → inaktiv

# Windows-Laufwerk gemountet?
ls -la /mnt/c
# → leeres Verzeichnis

# Welches powershell.exe?
which powershell.exe
# → /usr/local/bin/powershell.exe

Claude Code weiß nicht, dass sein powershell.exe in Wirklichkeit Bash ist. Es ist ihm egal. Die Zwischenablage funktioniert, der Wayland-Socket funktioniert, Claude Code funktioniert. Alles innerhalb der WSL2-Sandbox, alles ohne ein einziges Byte Zugriff auf das Windows-Dateisystem.

Was das über Abschottung lehrt

Es gibt eine Beobachtung, die ich aus diesem ganzen Debugging-Prozess mitgenommen habe, die über den konkreten Bug hinausgeht.

Die Abschottung hat den Bug nicht verursacht. Der Bug existierte unabhängig davon — in jedem WSL2-Setup, wo powershell.exe aus irgendeinem Grund nicht verfügbar ist. Die Abschottung hat ihn lediglich sichtbar gemacht. In den meisten WSL2-Setups mit aktivierter Interop läuft der PowerShell-Fix von Claude Code 2.1.70 still und unbemerkt im Hintergrund. Niemand weiß davon, niemand muss davon wissen, es funktioniert einfach.

Für mich funktionierte es nicht, weil mein Setup strenger ist als das, was Claude Code erwartet. Und weil ich, statt das Setup zu lockern, verstanden habe warum es nicht funktioniert — und eine Lösung gefunden habe, die das Setup respektiert.

Das ist, im Kern, der Wert von bewusster Konfiguration. Nicht als Selbstzweck, nicht als philosophische Übung — sondern weil man nur debuggen kann was man versteht. Wer seine Umgebung nicht kennt, kann ihre Fehler nicht lösen.

Ein Wort zur Ehrlichkeit in Sachen Sicherheit: Die Deaktivierung von Interop ist keine absolute Sicherheitsgrenze — sie ist eine sinnvolle Reduktion der Angriffsfläche. Schadsoftware in der WSL kann weiterhin Netzwerkverbindungen aufbauen und Daten exfiltrieren, die innerhalb der Sandbox liegen. Und der Wayland-Socket, den wir hier nutzen, ist tatsächlich ein neuer, schmaler Vektor: Schadsoftware in der WSL könnte theoretisch via wl-paste die Zwischenablage auslesen — inklusive Windows-Inhalte, die dort zwischengelagert sind. Das ist keine Paranoia, das ist eine reale Abwägung. Wer regelmäßig sensible Daten wie Passwörter über die Zwischenablage bewegt, sollte das im Hinterkopf behalten. Für meinen Use Case ist die Entscheidung klar: der Nutzen überwiegt das Risiko deutlich — aber ich wollte es nicht unerwähnt lassen.

Ein letzter praktischer Hinweis: Dieser Fix gilt für alle WSL2-Versionen von Claude Code die den PowerShell-Clipboard-Pfad verwenden — solange Anthropic das nicht ändert. Nach einem claude update lohnt sich ein kurzer Check:

which powershell.exe
# Sollte zeigen: /usr/local/bin/powershell.exe

Solange das eigene Script an erster Stelle im PATH steht, ist alles in Ordnung. Falls Claude Code jemals einen eigenen wl-clipboard-Codepath bekommt, kann das Script einfach entfernt werden — es hat keine Seiteneffekte.

Reproduzierbarkeit und Übertragbarkeit

Die Lösung funktioniert identisch auf Debian und Ubuntu unter WSL2 — vorausgesetzt Windows 11 ist der Host (WSLg ist Voraussetzung für Wayland) und wl-clipboard ist installiert.

Kurz zusammengefasst sind es drei Schritte: sudo apt install wl-clipboard , das Script aus dem vorherigen Abschnitt anlegen, testen. Wer eine direkte Copy-Paste-Vorlage möchte, findet alles nochmals gesammelt im Appendix.

Wer nicht abschottet — also interop enabled = true und Windows-PATH eingebunden hat — braucht das alles nicht. powershell.exe ist dann direkt verfügbar, Claude Codes eigener Fix greift, alles funktioniert ohne Zutun.

Dieser Artikel ist für die anderen: die, die wissen, warum sie abschotten, und die dafür nicht auf funktionierende Umlaute verzichten wollen.

Appendix: Copy-Paste-Vorlage

Für alle, die direkt loslegen wollen — die vollständige Anleitung in einem Block:

# 1. Abhängigkeit installieren
sudo apt install wl-clipboard

# 2. Fake-powershell.exe anlegen
# (/usr/local/bin gehört root, daher sudo tee statt cat >)
sudo tee /usr/local/bin/powershell.exe << 'EOF'
#!/bin/bash
if [[ "$*" == *"Set-Clipboard"* ]]; then
    cat | wl-copy
elif [[ "$*" == *"Get-Clipboard"* ]]; then
    wl-paste --no-newline  # LF statt CRLF — Claude Code ist hier tolerant
fi
EOF
sudo chmod +x /usr/local/bin/powershell.exe

# 3. Testen
echo "🔥 Neues aus der verrückten Hölle der Zeichensätze! 🤯" | /usr/local/bin/powershell.exe -Command "Set-Clipboard"
/usr/local/bin/powershell.exe -Command "Get-Clipboard -Raw"
# Erwartete Ausgabe: 🔥 Neues aus der verrückten Hölle der Zeichensätze! 🤯

# 4. Abschottung verifizieren
cat /proc/sys/fs/binfmt_misc/WSLInterop  # → inaktiv
ls -la /mnt/c                            # → leer
which powershell.exe                     # → /usr/local/bin/powershell.exe

WSL-Konfiguration (vollständige Abschottung)

/etc/wsl.conf:

[boot]
systemd=true
command = mount --make-rshared /

[automount]
enabled = false
mountFsTab = true

[interop]
enabled = false
appendWindowsPath = false

Danach: wsl --shutdown → WSL neu starten.

Was Claude Code intern aufruft

Zur Referenz — die exakten PowerShell-Befehle, die Claude Code verwendet und die unser Script abfängt:

# Clipboard setzen:
[Console]::InputEncoding = [Text.Encoding]::UTF8; Set-Clipboard -Value ([Console]::In.ReadToEnd())

# Clipboard lesen:
[Console]::OutputEncoding = [Text.Encoding]::UTF8; Get-Clipboard -Raw

Voraussetzungen: WSL2, Windows 11 (WSLg für Wayland), Debian oder Ubuntu. Nach einem claude update kurz prüfen ob which powershell.exe noch auf das eigene Script zeigt.