Pular para o conteúdo principal
Ao usar o Windsurf no WSL (via Remote - WSL), o editor pode ficar lento, parar de responder ou se desconectar repetidamente do backend do WSL. Isso normalmente é causado por extensões que fazem monitoramento e indexação de arquivos de forma agressiva sobre o sistema de arquivos do WSL, o que satura o protocolo Plan 9 (9P) — a ponte de sistema de arquivos entre o Windows e o ambiente Linux do WSL. Isso é mais provável em repositórios grandes e quando vários servidores de linguagem são executados simultaneamente.

​
Sintomas

  • Windsurf fica visivelmente lento ou com atraso quando conectado ao WSL
  • O editor se desconecta com frequência do back-end do WSL e tenta se reconectar
  • As desconexões ocorrem durante o desenvolvimento ativo (por exemplo, ao usar o Cascade) e enquanto o editor está ocioso
  • Windsurf trava ou fica sem resposta, exigindo reiniciar tanto o IDE quanto o WSL (wsl --shutdown)
  • O uso de memória do WSL aumenta ao longo do tempo, mesmo em sistemas com 32 GB+ de RAM
  • Os logs de diagnóstico do WSL mostram um grande número de eventos P9 Reply_Rlerror (erros de arquivo não encontrado)
  • O desempenho é normal ao usar o Windsurf fora do WSL (por exemplo, ao abrir uma pasta local do Windows)
  • Soluções paliativas comuns (reiniciar o WSL, reinstalar o Windsurf, aumentar a memória no .wslconfig) não resolvem o problema por si só

​
Causa raiz

A comunicação entre o Windows e o sistema de arquivos Linux do WSL usa o protocolo Plan 9 (9P), que tem uma taxa de transferência limitada em comparação com o acesso nativo ao sistema de arquivos. Quando extensões são instaladas no ambiente WSL, algumas realizam monitoramento e indexação de arquivos de forma agressiva em todo o workspace. Em repositórios grandes (por exemplo, 250.000+ arquivos, 5+ GB), isso gera um volume massivo de operações no sistema de arquivos através da ponte 9P, o que pode:
  • Saturar a capacidade do protocolo
  • Produzir milhares de erros de arquivo não encontrado (Reply_Rlerror)
  • Fazer com que a conexão entre o Windsurf e o backend do WSL caia
  • Contribuir para o aumento gradual da pressão de memória dentro do WSL ao longo do tempo
Isso é agravado quando múltiplos servidores de linguagem (language servers) também estão em execução (por exemplo, Sorbet, Ruby LSP, TypeScript etc.), já que eles adicionam mais sobrecarga de monitoramento de arquivos. A atividade combinada de acesso ao sistema de arquivos das extensões e dos servidores de linguagem pode sobrecarregar a ponte 9P mesmo em sistemas com 32 GB+ de RAM. Um exemplo conhecido é a extensão Vue (Volar), que já foi observada causando indexação excessiva de arquivos em ambientes WSL mesmo quando o workspace não contém arquivos Vue. Esse problema está documentado no ecossistema do VS Code: microsoft/vscode-remote-release#11091 Isso é especialmente provável se você tiver migrado um grande conjunto de extensões do VS Code ou de outro editor que não são necessárias para o seu projeto atual.

​
Soluções

​
1. Reinstalação limpa do servidor do Windsurf no WSL

Remova o diretório do servidor do Windsurf no WSL e deixe o Windsurf reinstalá-lo na próxima conexão: 
rm -rf ~/.windsurf-server
Em seguida, conecte novamente o Windsurf ao WSL. O servidor será reinstalado automaticamente.

​
2. Minimize o número de extensões instaladas (maior impacto)

Instale apenas as extensões de que você realmente precisa para o repositório em que está trabalhando.
  • Abra o painel de Extensões no Windsurf enquanto estiver conectado ao WSL
  • Revise quais extensões estão instaladas no ambiente WSL (não apenas localmente)
  • Desative ou desinstale as extensões de que você não precisa — especialmente aquelas que fazem monitoramento intenso de arquivos ou indexação
Extensões problemáticas conhecidas no WSL:
  • Vue (Volar) — foi confirmado que causa indexação excessiva de arquivos através da ponte 9P, mesmo em projetos que não usam Vue. Desinstalar apenas essa extensão já resolveu desconexões para vários usuários.
  • Outras extensões de linguagem específicas de frameworks (Angular, Svelte, etc.) podem se comportar de forma semelhante se estiverem instaladas, mas não forem necessárias para o workspace atual.
Não presuma que extensões que funcionam bem em uma configuração local (sem WSL) se comportarão da mesma forma no WSL. A ponte de sistema de arquivos 9P é o gargalo — extensões que são inofensivas localmente podem se tornar desestabilizadoras quando cada operação de arquivo precisa atravessar o limite do protocolo. Reduzir a atividade de sistema de arquivos gerada por extensões reduz diretamente a carga na ponte 9P.

​
3. Otimize os limites de recursos do WSL

Crie ou edite o arquivo %USERPROFILE%\.wslconfig no seu host Windows (por exemplo, C:\Users\<YourUser>\.wslconfig) com limites de recursos apropriados para o seu sistema: 
[wsl2]
memory=16GB
swap=4GB
processors=4
autoMemoryReclaim=gradual
Ajuste os valores de acordo com os recursos disponíveis no seu sistema. Depois de salvar o arquivo, reinicie o WSL: 
wsl --shutdown
Em seguida, reabra o Windsurf e reconecte-se ao WSL.

​
Diagnóstico

​
Verifique os logs de diagnóstico do WSL em busca de erros 9P

Para confirmar que a causa é a saturação do 9P, colete os logs de diagnóstico do WSL: 
wsl --debug-shell
Ou gere um pacote completo de diagnóstico: 
Invoke-WebRequest -UseBasicParsing "https://aka.ms/wsldiag" -OutFile wsldiag.ps1
.\wsldiag.ps1
Procure por altos volumes de eventos Reply_Rlerror nos logs do 9P/filesystem. Milhares (ou mais) normalmente indicam que extensões ou processos dentro do WSL estão gerando solicitações excessivas ao sistema de arquivos que a ponte 9P não consegue processar.

​
Quando usar cada correção

  • Minimizar extensões se você tiver muitas extensões instaladas no WSL que não usa ativamente ou se tiver migrado extensões de outro editor. (Mudança de maior impacto.)
  • Reinstalação limpa do servidor se o estado do servidor do Windsurf pode estar corrompido ou obsoleto (por exemplo, após uma atualização com falha ou um travamento anterior).
  • Otimizar .wslconfig se o WSL estiver consumindo recursos excessivos do host ou se você ainda não tiver configurado limites de recursos. (Melhora geral da estabilidade do WSL.)
Para melhores resultados, aplique as três. A combinação de um servidor limpo, extensões mínimas e limites de recursos ajustados aborda tanto a causa raiz (saturação de 9P devido à atividade de extensões) quanto os fatores que contribuem (esgotamento de recursos).