> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Problèmes connus de WSL
> Résolvez les problèmes connus de Devin Desktop lors de son utilisation avec Windows Subsystem for Linux (WSL), notamment les ralentissements dus à 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 présente les problèmes connus liés à l'utilisation de Devin Desktop avec Windows Subsystem for Linux (WSL), ainsi que les correctifs recommandés.
***
## **Lenteurs ou déconnexions (saturation du système de fichiers 9P)**
Lorsque vous utilisez Devin Desktop dans WSL (via **Remote - WSL**), l’éditeur peut devenir lent, ne plus répondre ou se déconnecter de façon répétée du backend WSL. Ce problème est le plus souvent causé par des extensions qui effectuent une surveillance et une indexation intensives des fichiers sur le système de fichiers WSL, ce qui sature le **protocole Plan 9 (9P)** — la passerelle du système de fichiers entre Windows et l’environnement Linux de WSL.
Ce problème est plus fréquent dans les grands dépôts et lorsque plusieurs serveurs de langage s’exécutent simultanément.
### **Symptômes**
* Devin Desktop est sensiblement 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 (p. ex., lors de l'utilisation de Cascade) **et** lorsque l'éditeur est inactif
* Devin Desktop plante ou ne répond plus, ce qui nécessite de redémarrer à la fois l'IDE et WSL (`wsl --shutdown`)
* L'utilisation de la mémoire par WSL augmente au fil du temps, même sur des systèmes disposant de plus de 32 Go de RAM
* Les log de diagnostic WSL affichent un grand nombre d'événements `P9 Reply_Rlerror` (erreurs de fichier introuvable)
* Les performances sont normales lors de l'utilisation de Devin Desktop en dehors de WSL (p. ex., en ouvrant un dossier Windows local)
* Les solutions de contournement courantes (redémarrer WSL, réinstaller Devin Desktop, augmenter la mémoire dans `.wslconfig`) ne suffisent pas à résoudre le problème
***
### **Cause racine**
La communication entre Windows et le système de fichiers Linux de WSL repose sur 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 agressive des fichiers et une indexation de l'ensemble de l'espace de travail. Dans les grands dépôts (p. ex. 250 000+ fichiers, 5+ Go), cela génère un volume massif d'opérations sur le système de fichiers via la passerelle 9P, ce qui peut :
* Saturer la capacité du protocole
* Produire des milliers d'erreurs « fichier introuvable » (`Reply_Rlerror`)
* Provoquer la déconnexion entre Devin Desktop et le backend WSL
* Contribuer à une pression mémoire croissante dans WSL au fil du temps
Le problème s'aggrave lorsque plusieurs serveurs de langage sont également en cours d'exécution (p. ex. Sorbet, Ruby LSP, TypeScript, etc.), car ils ajoutent une surcharge supplémentaire liée à la surveillance des fichiers. L'activité combinée sur le système de fichiers, due aux extensions et aux serveurs de langage, peut saturer la passerelle 9P, même sur des systèmes disposant de plus de 32 Go de RAM.
Un exemple connu est l'**extension Vue (Volar)**, qui a été observée comme provoquant une indexation excessive des fichiers dans les environnements WSL, même lorsque l'espace de travail 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)
Cela est particulièrement probable si vous avez conservé un grand nombre d'extensions provenant de VS Code ou d'un autre éditeur et dont vous n'avez pas besoin pour votre projet actuel.
***
### **Solutions**
#### **1. Mettez WSL à jour vers la dernière version (première étape recommandée)**
De nombreux problèmes de déconnexion et de performances dans WSL peuvent être résolus simplement en mettant à jour WSL. Les versions plus récentes de WSL apportent des améliorations à la stabilité du système de fichiers 9P et à la fiabilité des connexions.
Ouvrez **PowerShell** (ou l’invite de commandes) sur votre machine Windows et exécutez :
```
wsl --update
```
Ensuite, redémarrez WSL :
```
wsl --shutdown
```
Ouvrez à nouveau Devin Desktop et reconnectez-vous à WSL. Vous pouvez vérifier votre version de WSL avec :
```
wsl --version
```
WSL **2.7.3.0 et versions ultérieures** inclut des correctifs qui ont permis de résoudre des problèmes persistants de déconnexion pour les utilisateurs, même sans autre modification de configuration.
***
#### **2. Réinstallation propre du serveur Devin Desktop dans WSL**
Supprimez le répertoire du serveur Devin Desktop dans WSL, puis laissez Devin Desktop le réinstaller lors de la prochaine connexion :
```shell theme={null}
rm -rf ~/.windsurf-server
```
Reconnectez ensuite Devin Desktop à WSL. Le serveur sera réinstallé automatiquement.
***
#### **3. Réduisez au minimum les extensions installées (impact maximal)**
N’installez que les extensions dont vous avez réellement besoin pour le repository sur lequel vous travaillez.
* Ouvrez le panneau Extensions dans Devin Desktop lorsque vous êtes connecté à WSL
* Vérifiez quelles extensions sont installées dans l’environnement **WSL** (et pas seulement en local)
* Désactivez ou désinstallez les extensions dont vous n’avez pas besoin, en particulier celles qui effectuent une surveillance intensive des fichiers ou de l’indexation
**Extensions connues pour poser problème dans WSL :**
* **Vue (Volar)** — il est confirmé qu’elle provoque une indexation excessive des fichiers via la passerelle 9P, même dans des projets non-Vue. La désinstallation de cette seule extension a résolu les déconnexions pour plusieurs utilisateurs.
* D’autres extensions de langage spécifiques à un framework (Angular, Svelte, etc.) peuvent se comporter de la même manière si elles sont installées sans être nécessaires pour l’espace de travail actuel.
Ne **supposez pas** que des extensions qui fonctionnent bien dans une configuration locale (hors WSL) se comporteront de la même manière dans WSL. La passerelle du système de fichiers 9P est le goulot d’étranglement : des extensions inoffensives en local peuvent devenir déstabilisantes lorsque chaque opération sur un fichier doit traverser la limite du protocole.
Réduire l’activité du système de fichiers générée par les extensions réduit directement la charge sur la passerelle 9P.
***
#### **4. Optimiser les limites de ressources de WSL**
Créez ou modifiez le fichier `%USERPROFILE%\.wslconfig` sur votre hôte **Windows** (p. ex. `C:\Users\\.wslconfig`) en définissant des limites de ressources adaptées à votre système :
```
[wsl2]
memory=16GB
swap=4GB
processors=4
autoMemoryReclaim=gradual
```
> **Remarque :** Le paramètre `autoMemoryReclaim` a été supprimé dans WSL **2.7.3.0** et les versions ultérieures. Si vous utilisez WSL 2.7.3.0+, n’incluez pas cette ligne. Vous pouvez vérifier la version de WSL avec `wsl --version`.
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 Devin Desktop et reconnectez-vous à WSL.
***
### **Diagnostic**
#### **Vérifiez les logs de diagnostic de WSL pour détecter les erreurs 9P**
Pour confirmer que la saturation de 9P en est bien la cause, collectez les logs de diagnostic de WSL :
```
wsl --debug-shell
```
Ou récupérez un bundle de diagnostic complet :
```
Invoke-WebRequest -UseBasicParsing "https://aka.ms/wsldiag" -OutFile wsldiag.ps1
.\wsldiag.ps1
```
Recherchez un grand nombre d’événements `Reply_Rlerror` dans les logs 9P/du système de fichiers. Des milliers d’événements (ou davantage) indiquent généralement que des extensions ou des processus dans WSL génèrent un nombre excessif de requêtes au système de fichiers, que la passerelle 9P ne parvient pas à traiter assez vite.
***
### **Quand appliquer quel correctif**
* **Mettez d’abord WSL à jour** — de nombreux problèmes se résolvent simplement en exécutant `wsl --update`. WSL 2.7.3.0+ apporte d’importantes améliorations de stabilité. (Correctif le plus simple.)
* **Réduisez le nombre d’extensions** si de nombreuses extensions sont installées dans WSL sans vous être réellement utiles, ou si vous avez migré des extensions depuis un autre éditeur. (Changement le plus efficace.)
* **Réinstallez proprement le serveur** si l’état du serveur Devin Desktop risque d’être corrompu ou obsolète (p. ex. après une mise à jour échouée ou un plantage).
* **Optimisez `.wslconfig`** si WSL consomme trop de ressources sur 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, commencez par mettre WSL à jour, puis appliquez les autres correctifs selon les besoins. La combinaison d’une version de WSL à jour, d’un serveur propre, d’un nombre minimal d’extensions et de limites de ressources bien réglées permet de traiter à la fois la cause racine (la saturation de 9P due à l’activité des extensions) et les facteurs aggravants (l’épuisement des ressources).
***
## **Impossible de se connecter à WSL avec un VPN ou un logiciel Zero Trust**
Devin Desktop ne parvient pas à se connecter à WSL et affiche 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**
* Devin Desktop signale `Error resolving authority` / `install script returned non-zero exit status` lors de la connexion à WSL
* WSL lui-même fonctionne (`wsl -d Ubuntu -- echo hello` réussit), mais `curl` dépasse le délai d'attente dans WSL
* Le problème a commencé après l'installation ou la mise à jour d'un VPN ou d'un logiciel zero-trust
### **Cause racine**
Par défaut, WSL 2 achemine le trafic via un réseau virtuel basé sur NAT. Les VPN et les logiciels zero trust n’acheminent souvent pas le trafic provenant de ce réseau virtuel, si bien que le téléchargement du serveur Devin Desktop échoue sans message d’erreur.
### **Solution**
#### **1. Activer le mode réseau en miroir**
Modifiez le fichier de configuration de WSL pour activer le mode réseau en miroir (généralement `C:\Users\\.wslconfig`).
Ajoutez ce qui suit :
```ini theme={null}
[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true
```
Redémarrez ensuite WSL et nettoyez tout résidu d’une ancienne installation :
```
wsl --shutdown
wsl -d Ubuntu -- bash -c "rm -f ~/.windsurf-server/.installation_lock"
```
Rouvrez Devin Desktop et reconnectez-vous à WSL. Le serveur s’installera automatiquement.
> **Note :** nécessite WSL 2.0.0 ou version ultérieure. Exécutez `wsl --version` pour vérifier la version, puis `wsl --update` pour la mettre à jour si nécessaire.
#### **2. Alternative : désactiver temporairement le VPN**
Si vous ne pouvez pas modifier `.wslconfig`, désactivez votre VPN/ZTNA, laissez Devin Desktop installer le serveur, puis réactivez-le. Les prochaines mises à jour de Devin Desktop nécessiteront de nouveau un accès réseau depuis WSL.