Comment j’ai fait fonctionner le mode vocal de Claude Code via SSH

J’utilise Claude Code sur un serveur Linux distant via SSH. C’est un super setup — le serveur a plus de ressources et je peux y accéder de n’importe où. Mais quand j’ai essayé le mode vocal, je me suis heurté à un mur :

cannot find card '0'

Le micro ne fonctionnait pas. Voici pourquoi et comment j’ai résolu le problème.

Le problème

Le mode vocal de Claude Code a besoin d’un microphone. Sur ta machine locale c’est évident — tu as une carte son, un micro et un daemon audio qui gère tout. Mais mon serveur distant est exactement ça : un serveur. Pas de carte son, pas de micro, pas de matériel audio.

Quand Claude Code essaie d’accéder à l’audio, il se rabat sur ALSA (la couche audio bas niveau de Linux), qui cherche un périphérique physique. Il n’y en a pas. D’où l’erreur.

Pourquoi c’est résolvable

Le truc avec Linux : les systèmes audio comme PipeWire et PulseAudio ne sont pas liés au matériel — ce sont des daemons qui gèrent les flux audio. Et ils supportent la transparence réseau «nativement». Ça veut dire que tu peux rediriger ton microphone local vers une machine distante via SSH, proprement et en toute sécurité.

La solution

L’idée est simple :

1. Dis à ton daemon audio local d’accepter les connexions via TCP
2. Utilise la fonction de tunnel inversé de SSH pour rediriger ce port vers la machine distante
3. Dis à la machine distante d’utiliser ce tunnel comme serveur audio

Voyons ça étape par étape.

Étape 1 : Ouvre ton serveur audio local aux connexions TCP

Sur ta machine locale, copie la configuration PipeWire PulseAudio par défaut dans ton répertoire utilisateur :

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

Puis ouvre ~/.config/pipewire/pipewire-pulse.conf, trouve le bloc server.address et ajoute l’adresse TCP :

server.address = [
    "unix:native"
    "tcp:127.0.0.1:4713"   # localhost uniquement — pour la redirection audio SSH
]

Puis redémarre PipeWire :

systemctl --user restart pipewire pipewire-pulse

Ça dit à PipeWire d’écouter sur le port TCP 4713, mais uniquement sur localhost — donc pas exposé au réseau. Et comme c’est dans le fichier de configuration, ça persiste entre les redémarrages automatiquement.

Étape 2 : SSH avec tunnel inversé

Au lieu d’un simple ssh user@server, ajoute le flag -R :

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

Ça dit à SSH : «Tout ce qui se connecte au port 4713 sur la machine distante, renvoie-le au port 4713 de ma machine locale.» Le trafic audio circule dans la connexion SSH chiffrée.

Étape 3 : Dis à la machine distante où est le serveur audio

Une fois connecté au distant, définis cette variable d’environnement :

export PULSE_SERVER="tcp:127.0.0.1:4713"

Maintenant toute application utilisant PulseAudio/PipeWire se connectera à ce port — qui mène directement à ton micro local.

Étape 4 : Réparer ALSA

Certaines applications (y compris le fallback de Claude Code) utilisent ALSA directement, qui ne connaît pas PULSE_SERVER. Crée ~/.asoundrc sur la machine distante :

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

Ça dit à ALSA : route tout via PulseAudio au lieu de chercher du matériel local. Assure-toi que le paquet nécessaire est installé :

sudo apt install libasound2-plugins pulseaudio-utils

Étape 5 : Tester

Toujours sur le distant, lance :

pactl info

Si tout fonctionne, tu verras les infos du serveur audio de ta machine locale — y compris ton microphone comme source par défaut. C’est la confirmation.

Comment ça fonctionne vraiment

Ça aide de comprendre chaque pièce séparément avant de voir comment elles s’assemblent.

Comment PipeWire fonctionne normalement

Sur ta machine locale, PipeWire tourne comme un daemon en arrière-plan. Il possède ton micro physique et tes haut-parleurs. Les applications ne parlent pas directement au matériel — elles se connectent à PipeWire via un socket Unix (un fichier comme /run/user/1000/pulse/native) et disent «donne-moi de l’audio». PipeWire gère le matériel.

Ce que fait le module TCP

Normalement PipeWire n’écoute que sur ce socket Unix local. En ajoutant "tcp:127.0.0.1:4713" à la configuration PipeWire, tu lui dis : écoute aussi sur un port TCP sur localhost. Maintenant il accepte les mêmes requêtes audio via le réseau, pas seulement via le socket local.

Ce que fait le tunnel SSH

SSH a une fonction appelée redirection inversée de port (-R). Quand tu te connectes avec :

ssh -R 4713:127.0.0.1:4713 your-server

SSH dit à la machine distante : «Tout ce qui se connecte à TON port 4713, redirige-le à travers cette connexion SSH vers MON port 4713.»

Le tunnel ressemble donc à ça :

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

Ce que fait PULSE_SERVER

Sur le distant, PULSE_SERVER=tcp:127.0.0.1:4713 dit à toute application audio : «Ne cherche pas de daemon audio local — connecte-toi à cette adresse TCP.»

Vue d’ensemble

Tout assemblé, le chemin audio ressemble à ça :

%%{init: {"flowchart": {"useMaxWidth": false}} }%%
graph TD
    A["Claude Code (distant)"] --> B["tcp:127.0.0.1:4713 sur distant"]
    B --> C["tunnel inversé SSH"]
    C --> D["ton PipeWire local sur port 4713"]
    D --> E["ton microphone physique"]

Ta voix voyage du matériel à PipeWire au socket TCP au tunnel SSH au serveur distant à Claude Code. La machine distante n’a jamais besoin de son propre matériel audio.

Ce que fait .asoundrc

Certaines applications contournent PulseAudio/PipeWire entièrement et parlent directement à ALSA — la couche audio de plus bas niveau de Linux. ALSA ne connaît pas PULSE_SERVER. Le fichier ~/.asoundrc corrige ça en disant à ALSA : «Quand quelqu’un demande le périphérique audio par défaut, route-le via PulseAudio au lieu de chercher du matériel.» Ainsi même les applications basées sur ALSA passent par le même tunnel.

Rendre permanent

La configuration ci-dessus fonctionne pour une session. Pour la rendre permanente :

Sur le distant — PULSE_SERVER devrait être dans ~/.zshrc (ou ~/.bashrc) :

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

Pour SSH — ajoute RemoteForward à ~/.ssh/config sur ta machine locale pour ne pas avoir à taper le flag -R à chaque fois :

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

Maintenant un simple ssh your-server configure le tunnel automatiquement.

Pour le module TCP local — déjà géré à l’Étape 1. Le port 4713 s’ouvre automatiquement à chaque connexion.

Résumé

Cinq étapes, pas d’outils tiers, pas de configuration complexe. Juste Linux qui fait ce que Linux fait bien.