> ## Documentation Index
> Fetch the complete documentation index at: https://docs.windsurf.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Problèmes connus de WSL
> Résoudre les problèmes connus de Windsurf lors de l'exécution dans Windows Subsystem for Linux (WSL), notamment les problèmes de performances liés à la saturation du système de fichiers Plan 9 (9P) et les échecs de connexion causés par un VPN ou un logiciel réseau zero-trust.
Cette page répertorie les problèmes connus lors de l'utilisation de Windsurf avec Windows Subsystem for Linux (WSL) et les correctifs recommandés.
***
## **Performances lentes ou déconnexions (saturation du système de fichiers 9P)**
Lorsque vous utilisez Windsurf dans WSL (via **Remote - WSL**), l'éditeur peut devenir lent, ne plus répondre ou se déconnecter à plusieurs reprises du backend WSL. Cela est le plus souvent causé par des extensions qui effectuent une surveillance et une indexation agressives des fichiers sur le système de fichiers WSL, ce qui sature le **protocole Plan 9 (9P)** — la passerelle de système de fichiers entre Windows et l'environnement Linux WSL.
Ce problème est plus probable dans les grands dépôts de code et lorsque plusieurs serveurs de langage s'exécutent simultanément.
### **Symptômes**
* Windsurf devient nettement lent ou présente des latences lorsqu'il est connecté à WSL
* L'éditeur se déconnecte fréquemment du backend WSL et tente de se reconnecter
* Des déconnexions se produisent pendant le développement actif (par exemple lors de l'utilisation de Cascade) **et** lorsque l'éditeur est inactif
* Windsurf plante ou ne répond plus, nécessitant un redémarrage à la fois de l'IDE et de WSL (`wsl --shutdown`)
* L'utilisation mémoire de WSL augmente au fil du temps, même sur des systèmes avec 32 Go de RAM ou plus
* Les logs de diagnostic WSL montrent un grand nombre d'événements `P9 Reply_Rlerror` (erreurs de type « fichier introuvable »)
* Les performances sont normales lors de l'utilisation de Windsurf en dehors de WSL (par exemple en ouvrant un dossier local Windows)
* Les solutions de contournement habituelles (redémarrage de WSL, réinstallation de Windsurf, augmentation de la mémoire dans `.wslconfig`) ne résolvent pas le problème à elles seules
***
### **Cause principale**
La communication entre Windows et le système de fichiers Linux de WSL utilise le **protocole Plan 9 (9P)**, dont le débit est limité par rapport à un accès natif au système de fichiers.
Lorsque des extensions sont installées dans l'environnement WSL, certaines effectuent une surveillance et un indexage agressifs des fichiers sur l'ensemble du workspace. Dans de grands dépôts de code (par exemple 250 000+ fichiers, 5+ Go), cela génère un volume massif d'opérations sur le système de fichiers via le pont 9P, ce qui peut :
* Saturer la capacité du protocole
* Produire des milliers d'erreurs « fichier introuvable » (`Reply_Rlerror`)
* Provoquer la rupture de la connexion entre Windsurf et le backend WSL
* Contribuer, au fil du temps, à une pression croissante sur la mémoire à l'intérieur de WSL
Le problème est aggravé lorsque plusieurs serveurs de langage (language servers) s'exécutent également (par exemple Sorbet, Ruby LSP, TypeScript, etc.), car ils ajoutent une charge supplémentaire de surveillance des fichiers. L'activité combinée sur le système de fichiers provenant des extensions et des serveurs de langage peut submerger le pont 9P, même sur des systèmes disposant de 32 Go de RAM ou plus.
Un exemple connu est l'**extension Vue (Volar)**, qui a été observée comme provoquant un indexage excessif des fichiers dans les environnements WSL, même lorsque le workspace ne contient pas de fichiers Vue. Ce problème est documenté dans l'écosystème VS Code :
[microsoft/vscode-remote-release#11091](https://github.com/microsoft/vscode-remote-release/issues/11091)
Ce scénario est d’autant plus probable si vous avez conservé un grand ensemble d’extensions provenant de VS Code ou d’un autre éditeur qui ne sont pas nécessaires pour votre projet actuel.
***
### **Solutions**
#### **1. Réinstallation propre du serveur Windsurf sous WSL**
Supprimez le répertoire du serveur Windsurf sous WSL et laissez Windsurf le réinstaller à la prochaine connexion :
```shell theme={null}
rm -rf ~/.windsurf-server
```
Reconnectez ensuite Windsurf à WSL. Le serveur sera réinstallé automatiquement.
***
#### **2. Réduire au minimum les extensions installées (impact maximal)**
N'installez que les extensions dont vous avez réellement besoin pour le dépôt sur lequel vous travaillez.
* Ouvrez le panneau des extensions dans Windsurf lorsque vous êtes connecté à WSL
* Passez en revue les extensions installées dans l'environnement **WSL** (et pas seulement localement)
* Désactivez ou désinstallez les extensions dont vous n'avez pas besoin — en particulier celles qui effectuent une surveillance ou une indexation intensive des fichiers
**Extensions problématiques connues dans WSL :**
* **Vue (Volar)** — extension dont il est avéré qu'elle provoque une indexation de fichiers excessive via le pont 9P, même dans des projets non-Vue. La désinstallation de cette seule extension a permis de résoudre des déconnexions pour plusieurs utilisateurs.
* D'autres extensions de langage spécifiques à un framework (Angular, Svelte, etc.) peuvent se comporter de manière similaire si elles sont installées mais inutiles pour le workspace actuel.
Ne supposez **pas** que des extensions qui fonctionnent correctement sur une configuration locale (hors WSL) se comporteront de la même façon dans WSL. Le pont de système de fichiers 9P est le goulot d'étranglement — des extensions inoffensives en local peuvent devenir déstabilisantes lorsque chaque opération de fichier doit traverser la frontière imposée par le protocole.
Réduire l'activité du système de fichiers entraînée par les extensions diminue directement la charge sur le pont 9P.
***
#### **3. Optimiser les limites de ressources de WSL**
Créez ou modifiez le fichier `%USERPROFILE%\.wslconfig` sur votre hôte **Windows** (par exemple, `C:\Users\\.wslconfig`) en y définissant des limites de ressources adaptées à votre système :
```
[wsl2]
memory=16GB
swap=4GB
processors=4
autoMemoryReclaim=gradual
```
Ajustez les valeurs en fonction des ressources disponibles sur votre système.
Après avoir enregistré le fichier, redémarrez WSL :
```
wsl --shutdown
```
Rouvrez ensuite Windsurf et reconnectez-vous à WSL.
***
### **Diagnostic**
#### **Vérifiez les logs de diagnostic WSL à la recherche d'erreurs 9P**
Pour confirmer que la saturation de 9P est bien la cause, collectez les logs de diagnostic WSL :
```
wsl --debug-shell
```
Ou collectez un ensemble complet de diagnostics :
```
Invoke-WebRequest -UseBasicParsing "https://aka.ms/wsldiag" -OutFile wsldiag.ps1
.\wsldiag.ps1
```
Recherchez un grand nombre d’événements `Reply_Rlerror` dans les logs du système de fichiers 9P. Des milliers (ou plus) indiquent généralement que des extensions ou des processus WSL génèrent un volume excessif de requêtes au système de fichiers que le pont 9P n’arrive pas à traiter.
***
### **Quand utiliser quelle solution**
* **Limiter les extensions** si vous avez de nombreuses extensions installées dans WSL dont vous n'avez pas réellement besoin, ou si vous avez importé des extensions depuis un autre éditeur. (Changement à plus fort impact.)
* **Réinstallation propre du serveur** si l'état du serveur Windsurf est potentiellement corrompu ou obsolète (par exemple après une mise à jour ayant échoué ou un crash précédent).
* **Optimiser `.wslconfig`** si WSL consomme de manière excessive les ressources de l'hôte, ou si vous n'avez pas encore configuré de limites de ressources. (Amélioration générale de la stabilité de WSL.)
Pour de meilleurs résultats, appliquez les trois. La combinaison d'un serveur propre, d'un nombre minimal d'extensions et de limites de ressources ajustées traite à la fois la cause profonde (saturation 9P due à l'activité des extensions) et les facteurs contributifs (épuisement des ressources).
***
## **Impossible de se connecter à WSL avec un VPN ou un logiciel zero-trust**
Windsurf ne parvient pas à se connecter à WSL avec l'erreur `Couldn't install vscode server on remote server, install script returned non-zero exit status` lorsqu'un VPN ou un logiciel zero-trust (Twingate, Tailscale, Zscaler, Cloudflare WARP, GlobalProtect, etc.) bloque le trafic réseau sortant depuis WSL.
### **Symptômes**
* Windsurf affiche `Error resolving authority` / `install script returned non-zero exit status` lors de la connexion à WSL
* WSL fonctionne normalement (`wsl -d Ubuntu -- echo hello` réussit), mais `curl` expire à l'intérieur de WSL
* Le problème est apparu après l'installation ou la mise à jour d'un VPN ou d'un logiciel zero-trust
### **Cause principale**
WSL 2 achemine le trafic via un réseau virtuel basé sur NAT par défaut. Les logiciels VPN et zero-trust ne transfèrent souvent pas le trafic provenant de ce réseau virtuel, de sorte que le téléchargement du serveur Windsurf échoue silencieusement.
### **Solution**
#### **1. Activer le réseau en mode miroir (mirrored networking)**
Modifiez le fichier de configuration WSL pour activer le réseau en mode miroir (généralement `C:\Users\\.wslconfig`).
Ajoutez les lignes suivantes :
```ini theme={null}
[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true
```
Puis redémarrez WSL et nettoyez tout état d'installation obsolète :
```
wsl --shutdown
wsl -d Ubuntu -- bash -c "rm -f ~/.windsurf-server/.installation_lock"
```
Rouvrez Windsurf et reconnectez-vous à WSL. Le serveur s'installera automatiquement.
> **Remarque :** Nécessite WSL 2.0.0+. Exécutez `wsl --version` pour vérifier et `wsl --update` pour mettre à jour si nécessaire.
#### **2. Alternative : déconnecter temporairement le VPN**
Si vous ne pouvez pas modifier `.wslconfig`, déconnectez votre VPN/ZTNA, laissez Windsurf installer le serveur, puis reconnectez-vous. Les futures mises à jour de Windsurf nécessiteront à nouveau un accès réseau depuis WSL.