Saltar al contenido principal
Al usar Windsurf en WSL (a través de Remote - WSL), el editor puede volverse lento, dejar de responder o desconectarse repetidamente del backend de WSL. Esto suele deberse a que las extensiones realizan una monitorización e indexación de archivos agresivas sobre el sistema de archivos de WSL, lo que satura el protocolo Plan 9 (9P), el puente de sistema de archivos entre Windows y el entorno Linux de WSL. Esto es más probable en repositorios grandes y cuando varios servidores de lenguaje se ejecutan de forma concurrente.

Síntomas

  • Windsurf se vuelve notablemente lento o con mucho retraso cuando está conectado a WSL
  • El editor se desconecta con frecuencia del backend de WSL e intenta reconectarse
  • Se producen desconexiones durante el desarrollo activo (por ejemplo, al usar Cascade) y mientras el editor está inactivo
  • Windsurf se bloquea o deja de responder, lo que obliga a reiniciar tanto el IDE como WSL (wsl --shutdown)
  • El consumo de memoria de WSL aumenta con el tiempo, incluso en sistemas con más de 32 GB de RAM
  • Los logs de diagnóstico de WSL muestran un gran número de eventos P9 Reply_Rlerror (errores de archivo no encontrado)
  • El rendimiento es normal cuando se usa Windsurf fuera de WSL (por ejemplo, abriendo una carpeta local de Windows)
  • Las soluciones habituales (reiniciar WSL, reinstalar Windsurf, aumentar la memoria en .wslconfig) no resuelven el problema por sí solas

Causa raíz

La comunicación entre Windows y el sistema de archivos Linux de WSL utiliza el protocolo Plan 9 (9P), que tiene un rendimiento limitado en comparación con el acceso nativo al sistema de archivos. Cuando las extensiones se instalan en el entorno WSL, algunas realizan una supervisión e indexación de archivos muy agresivas en todo el workspace. En repositorios grandes (p. ej., más de 250.000 archivos, más de 5 GB), esto genera un volumen masivo de operaciones de sistema de archivos sobre el puente 9P, lo que puede:
  • Saturar la capacidad del protocolo
  • Producir miles de errores de archivo no encontrado (Reply_Rlerror)
  • Provocar que la conexión entre Windsurf y el backend de WSL se interrumpa
  • Contribuir al aumento de la presión de memoria dentro de WSL con el tiempo
Esto se agrava cuando también se están ejecutando varios servidores de lenguaje (p. ej., Sorbet, Ruby LSP, TypeScript, etc.), ya que añaden sobrecarga adicional de supervisión de archivos. La actividad combinada del sistema de archivos procedente de extensiones y servidores de lenguaje puede saturar el puente 9P incluso en sistemas con más de 32 GB de RAM. Un ejemplo conocido es la extensión Vue (Volar), que se ha observado que provoca una indexación excesiva de archivos en entornos WSL incluso cuando el workspace no contiene archivos Vue. Este problema está documentado en el ecosistema de VS Code: microsoft/vscode-remote-release#11091 Esto es especialmente probable si has arrastrado desde VS Code u otro editor un conjunto grande de extensiones que no son necesarias para tu proyecto actual.

Soluciones

1. Reinstalación limpia del servidor de Windsurf en WSL

Elimina el directorio del servidor de Windsurf dentro de WSL y deja que Windsurf lo vuelva a instalar en la siguiente conexión:
rm -rf ~/.windsurf-server
Luego vuelve a conectar Windsurf con WSL. El servidor se reinstalará automáticamente.

2. Minimiza las extensiones instaladas (mayor impacto)

Solo instala las extensiones que realmente necesitas para el repositorio en el que estás trabajando.
  • Abre el panel de Extensiones en Windsurf mientras estás conectado a WSL
  • Revisa qué extensiones están instaladas en el entorno WSL (no solo localmente)
  • Deshabilita o desinstala las extensiones que no necesitas, especialmente aquellas que realizan monitorización o indexación de archivos de forma intensiva
Extensiones problemáticas conocidas en WSL:
  • Vue (Volar): se ha confirmado que provoca una indexación de archivos excesiva a través del puente 9P, incluso en proyectos que no son de Vue. Desinstalar solo esta extensión ha resuelto las desconexiones para múltiples usuarios.
  • Otras extensiones de lenguaje específicas de un framework (Angular, Svelte, etc.) pueden comportarse de forma similar si están instaladas pero no son necesarias para el workspace actual.
No asumas que las extensiones que funcionan bien en una configuración local (sin WSL) se comportarán igual en WSL. El puente del sistema de archivos 9P es el cuello de botella: las extensiones que son inofensivas localmente pueden volverse desestabilizadoras cuando cada operación de archivo debe cruzar el límite del protocolo. Reducir la actividad del sistema de archivos generada por las extensiones reduce directamente la carga sobre el puente 9P.

3. Optimiza los límites de recursos de WSL

Crea o edita el archivo %USERPROFILE%\.wslconfig en tu equipo con Windows (por ejemplo, C:\Users\<YourUser>\.wslconfig) con límites de recursos adecuados para tu sistema:
[wsl2]
memory=16GB
swap=4GB
processors=4
autoMemoryReclaim=gradual
Ajusta los valores en función de los recursos disponibles de tu sistema. Después de guardar el archivo, reinicia WSL:
wsl --shutdown
Luego, vuelve a abrir Windsurf y reconéctate a WSL.

Diagnóstico

Comprueba los logs de diagnóstico de WSL para errores de 9P

Para confirmar que la saturación de 9P es la causa, recopila los logs de diagnóstico de WSL:
wsl --debug-shell
O genera un paquete de diagnóstico completo:
Invoke-WebRequest -UseBasicParsing "https://aka.ms/wsldiag" -OutFile wsldiag.ps1
.\wsldiag.ps1
Busque un alto volumen de eventos Reply_Rlerror en los logs del sistema de archivos 9P. Miles (o más) suelen indicar que las extensiones o procesos dentro de WSL están generando un número excesivo de solicitudes al sistema de archivos que el puente 9P no es capaz de procesar.

Cuándo usar cada solución

  • Minimizar extensiones si tienes muchas extensiones instaladas en WSL que no utilizas activamente, o si migraste tus extensiones desde otro editor. (Cambio de mayor impacto).
  • Reinstalación limpia del servidor si el estado del servidor de Windsurf puede estar dañado o desactualizado (por ejemplo, después de una actualización fallida o un bloqueo previo).
  • Optimizar .wslconfig si WSL está consumiendo recursos excesivos del host, o si no has configurado previamente los límites de recursos. (Mejora general de la estabilidad de WSL).
Para obtener mejores resultados, aplica las tres. La combinación de un servidor limpio, extensiones mínimas y límites de recursos ajustados aborda tanto la causa raíz (saturación de 9P por la actividad de extensiones) como los factores que contribuyen (agotamiento de recursos).