Wie ich den Sprachmodus von Claude Code über SSH zum Laufen gebracht habe

Ich habe Claude Code auf einem Remote-Linux-Server über SSH betrieben. Ein tolles Setup — der Server hat mehr Ressourcen, und ich kann von überall darauf zugreifen. Aber als ich den Sprachmodus ausprobierte, bin ich sofort gegen eine Wand gelaufen:

cannot find card '0'

Das Mikrofon funktionierte nicht. Hier ist der Grund und wie ich es behoben habe.

Das Problem

Der Sprachmodus von Claude Code braucht ein Mikrofon. Auf deinem lokalen Rechner ist das offensichtlich — du hast eine Soundkarte, ein Mikrofon und einen Audio-Daemon, der alles verwaltet. Aber mein Remote-Server ist genau das: ein Server. Keine Soundkarte, kein Mikrofon, keine Audio-Hardware.

Wenn Claude Code versucht, auf Audio zuzugreifen, fällt es auf ALSA zurück (die niedrigste Audio-Schicht von Linux), die nach einem physischen Gerät sucht. Es gibt keins. Daher der Fehler.

Warum das tatsächlich lösbar ist

Die Sache mit Linux ist: Audio-Systeme wie PipeWire und PulseAudio sind nicht an Hardware gebunden — sie sind Daemons, die Audio-Streams verwalten. Und sie unterstützen Netzwerktransparenz „von Haus aus“. Das bedeutet, du kannst dein lokales Mikrofon sauber und sicher über SSH an einen Remote-Rechner weiterleiten.

Die Lösung

Die Idee ist unkompliziert:

1. Sage deinem lokalen Audio-Daemon, dass er Verbindungen über TCP akzeptieren soll
2. Nutze die Reverse-Tunnel-Funktion von SSH, um diesen Port an den Remote-Rechner weiterzuleiten
3. Sage dem Remote-Rechner, dass er diesen Tunnel als Audio-Server nutzen soll

Gehen wir es Schritt für Schritt durch.

Schritt 1: Öffne deinen lokalen Audio-Server für TCP-Verbindungen

Auf deinem lokalen Rechner kopiere die Standard-PipeWire-PulseAudio-Konfiguration in dein Benutzerverzeichnis:

cp /usr/share/pipewire/pipewire-pulse.conf ~/.config/pipewire/pipewire-pulse.conf

Dann öffne ~/.config/pipewire/pipewire-pulse.conf, finde den server.address-Block und füge die TCP-Adresse hinzu:

server.address = [
    "unix:native"
    "tcp:127.0.0.1:4713"   # nur localhost — für SSH-Audio-Weiterleitung
]

Dann starte PipeWire neu:

systemctl --user restart pipewire pipewire-pulse

Das sagt PipeWire, auf TCP-Port 4713 zu lauschen, aber nur auf localhost — also nicht dem Netzwerk ausgesetzt. Und weil es in der Konfigurationsdatei steht, bleibt es über Neustarts hinweg bestehen.

Schritt 2: SSH mit Reverse-Tunnel

Statt einem einfachen ssh user@server füge das -R-Flag hinzu:

ssh -R 4713:127.0.0.1:4713 user@your-server

Das sagt SSH: „Alles, was sich auf dem Remote-Rechner mit Port 4713 verbindet, tunnel es zurück zu Port 4713 auf meinem lokalen Rechner.“ Der Audio-Traffic läuft innerhalb der verschlüsselten SSH-Verbindung.

Schritt 3: Sage dem Remote-Rechner, wo der Audio-Server ist

Sobald du auf dem Remote eingeloggt bist, setze diese Umgebungsvariable:

export PULSE_SERVER="tcp:127.0.0.1:4713"

Jetzt verbindet sich jede App, die PulseAudio/PipeWire nutzt, mit diesem Port — der direkt zurück zu deinem lokalen Mikrofon tunnelt.

Schritt 4: ALSA reparieren

Einige Apps (einschließlich des Fallbacks von Claude Code) nutzen ALSA direkt, das nichts von PULSE_SERVER weiß. Erstelle ~/.asoundrc auf dem Remote-Rechner:

pcm.!default { type pulse }
ctl.!default { type pulse }

Das sagt ALSA: Leite alles über PulseAudio, statt nach lokaler Hardware zu suchen. Stelle sicher, dass das benötigte Paket installiert ist:

sudo apt install libasound2-plugins pulseaudio-utils

Schritt 5: Testen

Noch auf dem Remote, führe aus:

pactl info

Wenn alles funktioniert, siehst du die Audio-Server-Informationen deines lokalen Rechners — einschließlich deines Mikrofons als Standardquelle. Das ist die Bestätigung.

Wie es tatsächlich funktioniert

Es hilft, jedes Teil einzeln zu verstehen, bevor man sieht, wie sie zusammenpassen.

Wie PipeWire normalerweise funktioniert

Auf deinem lokalen Rechner läuft PipeWire als Hintergrund-Daemon. Es besitzt dein physisches Mikrofon und deine Lautsprecher. Apps sprechen nicht direkt mit der Hardware — sie verbinden sich mit PipeWire über einen Unix-Socket (eine Datei wie /run/user/1000/pulse/native) und sagen „gib mir Audio“. PipeWire kümmert sich um die Hardware.

Was das TCP-Modul macht

Normalerweise lauscht PipeWire nur auf diesem lokalen Unix-Socket. Indem du "tcp:127.0.0.1:4713" zur PipeWire-Konfiguration hinzufügst, sagst du ihm: Lausche auch auf einem TCP-Port auf localhost. Jetzt akzeptiert es dieselben Audio-Anfragen über das Netzwerk, nicht nur über den lokalen Socket.

Was der SSH-Tunnel macht

SSH hat eine Funktion namens Reverse Port Forwarding (-R). Wenn du dich verbindest mit:

ssh -R 4713:127.0.0.1:4713 your-server

SSH sagt dem Remote-Rechner: „Alles, was sich mit DEINEM Port 4713 verbindet, leite es durch diese SSH-Verbindung zu MEINEM Port 4713 weiter.“

Der Tunnel sieht also so aus:

%%{init: {"flowchart": {"useMaxWidth": false}} }%%
graph LR
    A["remote:4713"] ==> B["SSH-Tunnel"] ==> C["localhost:4713 (dein PipeWire)"]

Was PULSE_SERVER macht

Auf dem Remote sagt PULSE_SERVER=tcp:127.0.0.1:4713 jeder Audio-App: „Suche nicht nach einem lokalen Audio-Daemon — verbinde dich stattdessen mit dieser TCP-Adresse.“

Das Gesamtbild

Alles zusammen sieht der Audio-Pfad so aus:

%%{init: {"flowchart": {"useMaxWidth": false}} }%%
graph TD
    A["Claude Code (Remote)"] --> B["tcp:127.0.0.1:4713 auf Remote"]
    B --> C["SSH-Reverse-Tunnel"]
    C --> D["dein lokales PipeWire auf Port 4713"]
    D --> E["dein physisches Mikrofon"]

Deine Stimme reist von Hardware zu PipeWire zu TCP-Socket zu SSH-Tunnel zu Remote-Server zu Claude Code. Der Remote-Rechner braucht niemals eigene Audio-Hardware.

Was .asoundrc macht

Einige Apps umgehen PulseAudio/PipeWire komplett und sprechen direkt mit ALSA — der niedrigeren Audio-Schicht von Linux. ALSA weiß nichts von PULSE_SERVER. Die ~/.asoundrc-Datei behebt das, indem sie ALSA sagt: „Wenn jemand nach dem Standard-Audiogerät fragt, leite es über PulseAudio, statt nach Hardware zu suchen.“ So landen auch ALSA-basierte Apps im selben Tunnel.

Dauerhaft einrichten

Das obige Setup funktioniert für eine Sitzung. Um es dauerhaft zu machen:

Auf dem Remote — PULSE_SERVER sollte in ~/.zshrc (oder ~/.bashrc) stehen:

echo "export PULSE_SERVER='tcp:127.0.0.1:4713'" >> ~/.zshrc

Für SSH — füge RemoteForward zu ~/.ssh/config auf deinem lokalen Rechner hinzu, damit du nicht jedes Mal das -R-Flag tippen musst:

Host your-server
    HostName your-server-ip
    User your-user
    RemoteForward 4713 127.0.0.1:4713

Jetzt richtet ein einfaches ssh your-server den Tunnel automatisch ein.

Für das lokale TCP-Modul — bereits in Schritt 1 erledigt. Port 4713 öffnet sich bei jedem Login automatisch.

Zusammenfassung

Fünf Schritte, keine Drittanbieter-Tools, keine komplexe Konfiguration. Einfach Linux, das tut, was Linux gut kann.