Codex no VS Code não carregava no Linux Mint: falha no sync de plugins, IPv6 quebrado (solução)

A developer on Linux Mint found that the OpenAI Codex extension in VS Code failed to load its interface due to plugin sync failures with ChatGPT and GitHub, compounded by a broken IPv6 route. Disabling IPv6 in NetworkManager and restarting the service restored the Codex interface. The issue was diagnosed by testing IPv4 and IPv6 connectivity to the relevant endpoints.

A interface da extensão Codex ficava completamente vazia no VS Code, enquanto os logs mostravam falhas ao sincronizar plugins com ChatGPT e GitHub. Este é o diagnóstico completo no Linux Mint e os passos que restauraram a interface. linux, vscode, openai, debugging, Codex, Linux Mint, VS Code, OpenAI, Plugins, IPv6, GitHub, NetworkManager, Troubleshooting Recentemente, a interface da extensão Codex deixou de carregar no meu VS Code no Linux Mint. O principal sintoma visual não era uma mensagem clara de erro: o painel do Codex simplesmente permanecia vazio. A extensão aparecia instalada, a aba era aberta, mas os controles principais e a área de conversa não carregavam. Ao verificar os logs da extensão, encontrei falhas relacionadas à sincronização do catálogo de plugins do Codex com os serviços do ChatGPT e com o GitHub. Este post registra o diagnóstico, os testes realizados e a sequência que restaurou a interface. O problema ocorreu no seguinte ambiente: Ao abrir a aba do Codex no VS Code, a interface permanecia praticamente vazia. Não apareciam normalmente: A única forma de entender o que estava acontecendo foi abrir os logs da extensão. Os primeiros logs indicavam falha ao acessar o catálogo remoto de plugins: WARN codex core plugins::manager: failed to load recommended plugins failed to send remote plugin catalog request to: https://chatgpt.com/backend-api/ps/plugins/suggested Também apareceram erros semelhantes durante o aquecimento dos caches: failed to warm featured plugin ids cache failed to warm remote plugin catalog cache failed to refresh remote installed plugins cache As chamadas que estavam falhando incluíam endpoints como: https://chatgpt.com/backend-api/plugins/featured https://chatgpt.com/backend-api/ps/plugins/list https://chatgpt.com/backend-api/ps/plugins/installed Inicialmente, isso parecia ser apenas uma falha no catálogo remoto do ChatGPT. Entretanto, depois de desativar o catálogo remoto, surgiu uma segunda mensagem mais específica. O log seguinte mostrou que o Codex também tentava sincronizar um repositório de plugins curados no GitHub: WARN codex core plugins::startup sync: GitHub HTTP sync failed for curated plugin sync failed to get curated plugins repository from: https://api.github.com/repos/openai/plugins O fallback por Git também falhou: git ls-remote curated plugins repo failed fatal: unable to access 'https://github.com/openai/plugins.git/': Could not resolve host: github.com O Codex ainda informou que um snapshot local já existia: skipping export archive fallback because a local curated plugins snapshot already exists Nesse ponto, o cenário era o seguinte: Para separar uma falha geral de internet de uma falha específica do Codex, testei o endpoint do ChatGPT diretamente. curl -4 -sS -o /dev/null \ -w 'HTTP IPv4: %{http code}\n' \ --connect-timeout 15 \ 'https://chatgpt.com/backend-api/plugins/featured?platform=codex' Resultado: HTTP IPv4: 401 O código 401 era aceitável para esse teste. O objetivo não era acessar o conteúdo autenticado, mas confirmar que: Portanto, o IPv4 estava operacional. curl -6 -sS -o /dev/null \ -w 'HTTP IPv6: %{http code}\n' \ --connect-timeout 15 \ 'https://chatgpt.com/backend-api/plugins/featured?platform=codex' Resultado: curl: 28 Failed to connect to chatgpt.com port 443 after 15002 ms: Timeout was reached HTTP IPv6: 000 Isso confirmou um segundo problema: o sistema possuía IPv6 configurado ou anunciado, mas a rota IPv6 não estava funcional. Aplicações que tentassem IPv6 antes do IPv4 poderiam esperar pelo timeout antes de continuar. Também conferi se o VS Code ou o Codex estavam herdando variáveis de proxy: env | grep -iE '^ http|https|all|no proxy=' O comando não retornou nenhum valor. Portanto, não havia evidência de: HTTP PROXY ; HTTPS PROXY ; ALL PROXY ; NO PROXY .O proxy foi descartado como causa. A recuperação aconteceu em duas frentes: Apenas usar Developer: Reload Window não foi suficiente. Abri o arquivo global de configuração: code ~/.codex/config.toml Também seria possível usar: nano ~/.codex/config.toml Na seção features , adicionei: features plugins = false remote plugin = false Caso a seção features já exista, devem ser adicionadas somente as duas propriedades: plugins = false remote plugin = false Não devem existir duas seções features no mesmo arquivo TOML. A configuração completa ficou estruturalmente assim: features plugins = false remote plugin = false Essa alteração desabilita temporariamente: O núcleo do Codex continua utilizável, mas recursos fornecidos por plugins deixam de estar disponíveis enquanto as flags estiverem desativadas. Fechei as janelas do VS Code e encerrei os processos restantes: pkill -f codex || true pkill -f '/usr/share/code/code' || true O caminho do segundo comando pode variar caso o VS Code tenha sido instalado por Snap, Flatpak ou outro método. O objetivo era garantir que o app-server e o processo da extensão não permanecessem ativos em segundo plano. Depois, removi somente os diretórios temporários de clones de plugins: find ~/.codex/.tmp \ -maxdepth 1 \ -type d \ -name 'plugins-clone- ' \ -print \ -exec rm -rf -- {} + \ 2 /dev/null Esse comando é restrito a diretórios chamados: plugins-clone- dentro de: ~/.codex/.tmp Não apaguei toda a pasta ~/.codex . Isso foi importante porque ~/.codex também pode conter: Depois da limpeza, iniciei novamente: code Nesse ponto, a interface do Codex carregou normalmente. Voltaram a aparecer: Portanto, a recuperação visual aconteceu após a combinação de: Embora a interface já tivesse voltado, o teste anterior mostrou que o IPv6 da conexão estava indisponível. Para evitar que aplicações tentassem uma rota IPv6 quebrada antes de usar IPv4, configurei o Linux para priorizar IPv4. Executei: grep -q '^precedence ::ffff:0:0/96 100$' /etc/gai.conf \ || echo 'precedence ::ffff:0:0/96 100' \ | sudo tee -a /etc/gai.conf A linha adicionada foi: precedence ::ffff:0:0/96 100 Essa configuração não remove o IPv6 da máquina. Ela altera a prioridade utilizada pelo resolvedor do sistema, favorecendo endereços IPv4 mapeados quando IPv4 e IPv6 estão disponíveis. Depois, reiniciei o NetworkManager: sudo systemctl restart NetworkManager Verifiquei a resolução dos serviços envolvidos: getent ahostsv4 chatgpt.com getent ahostsv4 github.com getent ahostsv4 api.github.com Os três comandos retornaram endereços IPv4. Não é recomendável copiar IPs específicos para configurações fixas, porque esses endereços podem mudar. Testei a API do GitHub: curl -4 -I --connect-timeout 15 https://api.github.com Resultado principal: HTTP/2 200 Depois testei o site principal: curl -4 -I --connect-timeout 15 https://github.com Resultado principal: HTTP/2 200 Por fim, validei exatamente a operação Git que havia falhado nos logs: git ls-remote https://github.com/openai/plugins.git HEAD O comando retornou: <commit-hash HEAD Isso confirmou que: github.com estava resolvendo; ls-remote não estava mais bloqueada.Não foi possível provar uma causa única e isolada. As evidências apontaram para uma combinação de fatores: O Codex tentava carregar: Essas operações estavam falhando durante a inicialização. Recarregar somente a janela do VS Code não reiniciou completamente toda a camada local do Codex. O encerramento explícito dos processos foi necessário. Existiam diretórios relacionados aos clones temporários dos plugins. A remoção foi limitada aos diretórios plugins-clone- . O IPv4 funcionava, mas o IPv6 terminava em timeout. Isso poderia introduzir atrasos e falhas em aplicações que priorizassem IPv6. O log registrou: Could not resolve host: github.com Posteriormente, os testes com getent , curl e git ls-remote funcionaram. Por isso, não é correto afirmar que havia uma falha permanente de DNS. A falha pode ter sido: Neste caso, não foi necessário: ~/.codex ;Essas ações seriam mais invasivas e poderiam eliminar configurações válidas sem atacar a causa real. A desativação dos plugins deve ser tratada como workaround controlado. Depois de uma atualização do Codex ou da estabilização da rede, os recursos podem ser testados novamente, uma flag de cada vez. Primeiro, testar apenas o catálogo remoto: features plugins = false remote plugin = true Depois de reiniciar completamente o Codex e o VS Code, verificar os logs. Se estiver estável, testar o subsistema completo: features plugins = true remote plugin = true Caso a interface volte a ficar vazia, retornar para: features plugins = false remote plugin = false Essa estratégia ajuda a identificar se o problema está: Comandos como: curl -I podem retornar cabeçalhos como: set-cookie authorization x-github-request-id Antes de publicar logs em blogs, fóruns ou issues, remova: Para documentação pública, normalmente basta mostrar: HTTP/2 200 ou a mensagem específica de erro. A sequência que resolveu o problema foi: code ~/.codex/config.toml Adicionar: features plugins = false remote plugin = false Encerrar os processos: pkill -f codex || true pkill -f '/usr/share/code/code' || true Remover clones temporários: find ~/.codex/.tmp \ -maxdepth 1 \ -type d \ -name 'plugins-clone- ' \ -print \ -exec rm -rf -- {} + \ 2 /dev/null Abrir novamente: code Depois, como estabilização de rede: grep -q '^precedence ::ffff:0:0/96 100$' /etc/gai.conf \ || echo 'precedence ::ffff:0:0/96 100' \ | sudo tee -a /etc/gai.conf sudo systemctl restart NetworkManager Validar: getent ahostsv4 chatgpt.com getent ahostsv4 github.com getent ahostsv4 api.github.com curl -4 -I --connect-timeout 15 https://api.github.com curl -4 -I --connect-timeout 15 https://github.com git ls-remote https://github.com/openai/plugins.git HEAD O ponto mais enganoso desse problema era visual. A extensão não apresentava uma tela explícita de falha: a interface simplesmente não carregava. Os logs mostraram que o Codex estava falhando durante operações de sincronização de plugins. A recuperação exigiu desativar temporariamente essa camada, encerrar completamente os processos locais e remover clones temporários. Separadamente, os testes revelaram uma rota IPv6 quebrada, enquanto o IPv4 permanecia funcional. Priorizar IPv4 reduziu o risco de novos timeouts. A principal lição foi não tratar uma interface vazia como simples falha visual do VS Code. Nesse caso, o problema estava no fluxo de inicialização do processo local do Codex e nas dependências de rede acionadas durante a sincronização de plugins. A documentação oficial confirma que a extensão do VS Code é alimentada pelo Codex app-server e que CLI e extensão compartilham as configurações de ~/.codex/config.toml . A referência de configuração também documenta features.remote plugin , enquanto o repositório oficial registra problemas recentes relacionados à sincronização e aos diretórios temporários de plugins.