Este é um guia prático para desenvolvedores que migraram suas aplicações para o diretório nativo do WSL (ex: ~/home/usuario/…) e estão enfrentando os dois problemas mais comuns: falhas de autenticação com o Azure DevOps e erros de permissão de arquivos ao trocar de branch.

Mover sua aplicação para dentro do sistema de arquivos do Linux (WSL) aumenta drasticamente a performance, mas pode quebrar a comunicação com o Gerenciador de Credenciais do Windows e gerar conflitos de permissão. Veja como resolver.

1. Integrando o Git do WSL com o Windows Link para o cabeçalho

Ao tentar fazer um push ou pull de dentro do WSL, o Linux não consegue acessar automaticamente suas senhas salvas no Windows. A melhor solução é fazer o Git do Linux “pedir emprestado” o Gerenciador de Credenciais do Windows.

Passo 1: Configurar o Helper de Credenciais Link para o cabeçalho

Execute o comando abaixo no terminal do seu WSL para apontar para o executável do Windows:

git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"

Passo 2: Ajustar a URL para o Azure DevOps Link para o cabeçalho

Se você usa o Azure DevOps (URLs como dev.azure.com), o Git precisa de uma configuração extra para identificar corretamente a sua Organização. Sem isso, você receberá o erro: “Cannot determine the organization name”.

Rode estes dois comandos:

# Permite que o Git use o caminho completo da URL para buscar a senha
git config --global credential.useHttpPath true

# Configura especificamente o provedor do Azure
git config --global credential.azure.dev.azure.com.useHttpPath true

O que acontece agora? Na próxima vez que você fizer um git push, uma janela pop-up nativa do Windows aparecerá para você realizar o login. Uma vez logado, a credencial fica salva no Windows e o WSL a utiliza automaticamente.

2. Resolvendo Erros de Permissão (Permission Denied) Link para o cabeçalho

Se ao trocar de branch (git checkout) você receber avisos como warning: unable to unlink… Permission denied, significa que o Linux não tem autoridade total para manipular os arquivos na pasta.

Por que isso acontece? Link para o cabeçalho

Isso geralmente ocorre porque os arquivos foram movidos do Windows para o Linux e mantiveram metadados restritivos, ou algum processo (como o VS Code ou um container Docker) está travando o arquivo.

Solução A: Resetar o Dono da Pasta Link para o cabeçalho

Garanta que seu usuário atual do Linux seja o dono de todos os arquivos do projeto:

# Substitui o dono de todos os arquivos pelo seu usuário atual
sudo chown -R $USER:$USER ~/caminho/do/seu/projeto

# Define permissões de leitura e escrita padrão
chmod -R 755 ~/caminho/do/seu/projeto

Solução B: Liberar Arquivos Travados Link para o cabeçalho

Se o erro persistir, o Windows pode estar “segurando” o arquivo.

  1. Feche o VS Code.

  2. No PowerShell do Windows, force o desligamento do WSL:

wsl --shutdown
  1. Abra o WSL novamente e tente o comando Git.

Dicas de Ouro para WSL Link para o cabeçalho

  • Abra pelo Terminal: Para evitar bugs de permissão, sempre abra seu projeto digitando code . dentro da pasta no terminal do Linux, em vez de arrastar a pasta \\wsl.localhost\... para dentro do VS Code.

  • Extensão WSL: Certifique-se de que a extensão WSL (da Microsoft) está instalada no seu VS Code. O rodapé do editor deve exibir um selo azul escrito WSL: Ubuntu.

Sua autenticação e permissões agora devem estar funcionando perfeitamente!