Passer au contenu principal
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 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 : 
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\<YourUser>\.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\<YourUser>\.wslconfig). Ajoutez les lignes suivantes : 
[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.