{"slug": "codex-no-vs-code-nao-carregava-no-linux-mint-falha-no-sync-de-plugins-ipv6", "title": "Codex no VS Code não carregava no Linux Mint: falha no sync de plugins, IPv6 quebrado (solução)", "summary": "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.", "body_md": "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.\n\n```\n#linux, #vscode, #openai, #debugging, #Codex, #Linux Mint, #VS Code, #OpenAI, #Plugins, #IPv6, #GitHub, #NetworkManager, #Troubleshooting\n```\n\nRecentemente, a interface da extensão Codex deixou de carregar no meu VS Code no Linux Mint.\n\nO 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.\n\nAo 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.\n\nEste post registra o diagnóstico, os testes realizados e a sequência que restaurou a interface.\n\nO problema ocorreu no seguinte ambiente:\n\nAo abrir a aba do Codex no VS Code, a interface permanecia praticamente vazia.\n\nNão apareciam normalmente:\n\nA única forma de entender o que estava acontecendo foi abrir os logs da extensão.\n\nOs primeiros logs indicavam falha ao acessar o catálogo remoto de plugins:\n\n```\nWARN codex_core_plugins::manager:\nfailed to load recommended plugins\n\nfailed to send remote plugin catalog request to:\nhttps://chatgpt.com/backend-api/ps/plugins/suggested\n```\n\nTambém apareceram erros semelhantes durante o aquecimento dos caches:\n\n```\nfailed to warm featured plugin ids cache\n\nfailed to warm remote plugin catalog cache\n\nfailed to refresh remote installed plugins cache\n```\n\nAs chamadas que estavam falhando incluíam endpoints como:\n\n```\nhttps://chatgpt.com/backend-api/plugins/featured\nhttps://chatgpt.com/backend-api/ps/plugins/list\nhttps://chatgpt.com/backend-api/ps/plugins/installed\n```\n\nInicialmente, isso parecia ser apenas uma falha no catálogo remoto do ChatGPT.\n\nEntretanto, depois de desativar o catálogo remoto, surgiu uma segunda mensagem mais específica.\n\nO log seguinte mostrou que o Codex também tentava sincronizar um repositório de plugins curados no GitHub:\n\n```\nWARN codex_core_plugins::startup_sync:\n\nGitHub HTTP sync failed for curated plugin sync\n\nfailed to get curated plugins repository from:\nhttps://api.github.com/repos/openai/plugins\n```\n\nO fallback por Git também falhou:\n\n```\ngit ls-remote curated plugins repo failed\n\nfatal: unable to access\n'https://github.com/openai/plugins.git/':\n\nCould not resolve host: github.com\n```\n\nO Codex ainda informou que um snapshot local já existia:\n\n```\nskipping export archive fallback because\na local curated plugins snapshot already exists\n```\n\nNesse ponto, o cenário era o seguinte:\n\nPara separar uma falha geral de internet de uma falha específica do Codex, testei o endpoint do ChatGPT diretamente.\n\n```\ncurl -4 -sS -o /dev/null \\\n  -w 'HTTP IPv4: %{http_code}\\n' \\\n  --connect-timeout 15 \\\n  'https://chatgpt.com/backend-api/plugins/featured?platform=codex'\n```\n\nResultado:\n\n```\nHTTP IPv4: 401\n```\n\nO código `401`\n\nera aceitável para esse teste.\n\nO objetivo não era acessar o conteúdo autenticado, mas confirmar que:\n\nPortanto, o IPv4 estava operacional.\n\n```\ncurl -6 -sS -o /dev/null \\\n  -w 'HTTP IPv6: %{http_code}\\n' \\\n  --connect-timeout 15 \\\n  'https://chatgpt.com/backend-api/plugins/featured?platform=codex'\n```\n\nResultado:\n\n```\ncurl: (28) Failed to connect to chatgpt.com port 443\nafter 15002 ms: Timeout was reached\n\nHTTP IPv6: 000\n```\n\nIsso confirmou um segundo problema: o sistema possuía IPv6 configurado ou anunciado, mas a rota IPv6 não estava funcional.\n\nAplicações que tentassem IPv6 antes do IPv4 poderiam esperar pelo timeout antes de continuar.\n\nTambém conferi se o VS Code ou o Codex estavam herdando variáveis de proxy:\n\n```\nenv | grep -iE '^(http|https|all|no)_proxy='\n```\n\nO comando não retornou nenhum valor.\n\nPortanto, não havia evidência de:\n\n`HTTP_PROXY`\n\n;`HTTPS_PROXY`\n\n;`ALL_PROXY`\n\n;`NO_PROXY`\n\n.O proxy foi descartado como causa.\n\nA recuperação aconteceu em duas frentes:\n\nApenas usar `Developer: Reload Window`\n\nnão foi suficiente.\n\nAbri o arquivo global de configuração:\n\n```\ncode ~/.codex/config.toml\n```\n\nTambém seria possível usar:\n\n```\nnano ~/.codex/config.toml\n```\n\nNa seção `[features]`\n\n, adicionei:\n\n```\n[features]\nplugins = false\nremote_plugin = false\n```\n\nCaso a seção `[features]`\n\njá exista, devem ser adicionadas somente as duas propriedades:\n\n```\nplugins = false\nremote_plugin = false\n```\n\nNão devem existir duas seções `[features]`\n\nno mesmo arquivo TOML.\n\nA configuração completa ficou estruturalmente assim:\n\n```\n[features]\nplugins = false\nremote_plugin = false\n```\n\nEssa alteração desabilita temporariamente:\n\nO núcleo do Codex continua utilizável, mas recursos fornecidos por plugins deixam de estar disponíveis enquanto as flags estiverem desativadas.\n\nFechei as janelas do VS Code e encerrei os processos restantes:\n\n```\npkill -f codex || true\npkill -f '/usr/share/code/code' || true\n```\n\nO caminho do segundo comando pode variar caso o VS Code tenha sido instalado por Snap, Flatpak ou outro método.\n\nO objetivo era garantir que o `app-server`\n\ne o processo da extensão não permanecessem ativos em segundo plano.\n\nDepois, removi somente os diretórios temporários de clones de plugins:\n\n```\nfind ~/.codex/.tmp \\\n  -maxdepth 1 \\\n  -type d \\\n  -name 'plugins-clone-*' \\\n  -print \\\n  -exec rm -rf -- {} + \\\n  2>/dev/null\n```\n\nEsse comando é restrito a diretórios chamados:\n\n```\nplugins-clone-*\n```\n\ndentro de:\n\n```\n~/.codex/.tmp\n```\n\nNão apaguei toda a pasta `~/.codex`\n\n.\n\nIsso foi importante porque `~/.codex`\n\ntambém pode conter:\n\nDepois da limpeza, iniciei novamente:\n\n```\ncode\n```\n\nNesse ponto, a interface do Codex carregou normalmente.\n\nVoltaram a aparecer:\n\nPortanto, a recuperação visual aconteceu após a combinação de:\n\nEmbora a interface já tivesse voltado, o teste anterior mostrou que o IPv6 da conexão estava indisponível.\n\nPara evitar que aplicações tentassem uma rota IPv6 quebrada antes de usar IPv4, configurei o Linux para priorizar IPv4.\n\nExecutei:\n\n```\ngrep -q '^precedence ::ffff:0:0/96  100$' /etc/gai.conf \\\n  || echo 'precedence ::ffff:0:0/96  100' \\\n  | sudo tee -a /etc/gai.conf\n```\n\nA linha adicionada foi:\n\n```\nprecedence ::ffff:0:0/96  100\n```\n\nEssa configuração não remove o IPv6 da máquina.\n\nEla altera a prioridade utilizada pelo resolvedor do sistema, favorecendo endereços IPv4 mapeados quando IPv4 e IPv6 estão disponíveis.\n\nDepois, reiniciei o NetworkManager:\n\n```\nsudo systemctl restart NetworkManager\n```\n\nVerifiquei a resolução dos serviços envolvidos:\n\n```\ngetent ahostsv4 chatgpt.com\ngetent ahostsv4 github.com\ngetent ahostsv4 api.github.com\n```\n\nOs três comandos retornaram endereços IPv4.\n\nNão é recomendável copiar IPs específicos para configurações fixas, porque esses endereços podem mudar.\n\nTestei a API do GitHub:\n\n```\ncurl -4 -I --connect-timeout 15 https://api.github.com\n```\n\nResultado principal:\n\n```\nHTTP/2 200\n```\n\nDepois testei o site principal:\n\n```\ncurl -4 -I --connect-timeout 15 https://github.com\n```\n\nResultado principal:\n\n```\nHTTP/2 200\n```\n\nPor fim, validei exatamente a operação Git que havia falhado nos logs:\n\n```\ngit ls-remote https://github.com/openai/plugins.git HEAD\n```\n\nO comando retornou:\n\n```\n<commit-hash>    HEAD\n```\n\nIsso confirmou que:\n\n`github.com`\n\nestava resolvendo;`ls-remote`\n\nnão estava mais bloqueada.Não foi possível provar uma causa única e isolada.\n\nAs evidências apontaram para uma combinação de fatores:\n\nO Codex tentava carregar:\n\nEssas operações estavam falhando durante a inicialização.\n\nRecarregar somente a janela do VS Code não reiniciou completamente toda a camada local do Codex.\n\nO encerramento explícito dos processos foi necessário.\n\nExistiam diretórios relacionados aos clones temporários dos plugins.\n\nA remoção foi limitada aos diretórios `plugins-clone-*`\n\n.\n\nO IPv4 funcionava, mas o IPv6 terminava em timeout.\n\nIsso poderia introduzir atrasos e falhas em aplicações que priorizassem IPv6.\n\nO log registrou:\n\n```\nCould not resolve host: github.com\n```\n\nPosteriormente, os testes com `getent`\n\n, `curl`\n\ne `git ls-remote`\n\nfuncionaram.\n\nPor isso, não é correto afirmar que havia uma falha permanente de DNS.\n\nA falha pode ter sido:\n\nNeste caso, não foi necessário:\n\n`~/.codex`\n\n;Essas ações seriam mais invasivas e poderiam eliminar configurações válidas sem atacar a causa real.\n\nA desativação dos plugins deve ser tratada como workaround controlado.\n\nDepois de uma atualização do Codex ou da estabilização da rede, os recursos podem ser testados novamente, uma flag de cada vez.\n\nPrimeiro, testar apenas o catálogo remoto:\n\n```\n[features]\nplugins = false\nremote_plugin = true\n```\n\nDepois de reiniciar completamente o Codex e o VS Code, verificar os logs.\n\nSe estiver estável, testar o subsistema completo:\n\n```\n[features]\nplugins = true\nremote_plugin = true\n```\n\nCaso a interface volte a ficar vazia, retornar para:\n\n```\n[features]\nplugins = false\nremote_plugin = false\n```\n\nEssa estratégia ajuda a identificar se o problema está:\n\nComandos como:\n\n```\ncurl -I\n```\n\npodem retornar cabeçalhos como:\n\n```\nset-cookie\nauthorization\nx-github-request-id\n```\n\nAntes de publicar logs em blogs, fóruns ou issues, remova:\n\nPara documentação pública, normalmente basta mostrar:\n\n```\nHTTP/2 200\n```\n\nou a mensagem específica de erro.\n\nA sequência que resolveu o problema foi:\n\n```\ncode ~/.codex/config.toml\n```\n\nAdicionar:\n\n```\n[features]\nplugins = false\nremote_plugin = false\n```\n\nEncerrar os processos:\n\n```\npkill -f codex || true\npkill -f '/usr/share/code/code' || true\n```\n\nRemover clones temporários:\n\n```\nfind ~/.codex/.tmp \\\n  -maxdepth 1 \\\n  -type d \\\n  -name 'plugins-clone-*' \\\n  -print \\\n  -exec rm -rf -- {} + \\\n  2>/dev/null\n```\n\nAbrir novamente:\n\n```\ncode\n```\n\nDepois, como estabilização de rede:\n\n```\ngrep -q '^precedence ::ffff:0:0/96  100$' /etc/gai.conf \\\n  || echo 'precedence ::ffff:0:0/96  100' \\\n  | sudo tee -a /etc/gai.conf\nsudo systemctl restart NetworkManager\n```\n\nValidar:\n\n```\ngetent ahostsv4 chatgpt.com\ngetent ahostsv4 github.com\ngetent ahostsv4 api.github.com\ncurl -4 -I --connect-timeout 15 https://api.github.com\ncurl -4 -I --connect-timeout 15 https://github.com\ngit ls-remote https://github.com/openai/plugins.git HEAD\n```\n\nO ponto mais enganoso desse problema era visual.\n\nA extensão não apresentava uma tela explícita de falha: a interface simplesmente não carregava.\n\nOs 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.\n\nSeparadamente, os testes revelaram uma rota IPv6 quebrada, enquanto o IPv4 permanecia funcional. Priorizar IPv4 reduziu o risco de novos timeouts.\n\nA 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.\n\nA documentação oficial confirma que a extensão do VS Code é alimentada pelo `Codex app-server`\n\ne que CLI e extensão compartilham as configurações de `~/.codex/config.toml`\n\n. A referência de configuração também documenta `features.remote_plugin`\n\n, enquanto o repositório oficial registra problemas recentes relacionados à sincronização e aos diretórios temporários de plugins.", "url": "https://wpnews.pro/news/codex-no-vs-code-nao-carregava-no-linux-mint-falha-no-sync-de-plugins-ipv6", "canonical_source": "https://dev.to/sevahc/codex-no-vs-code-nao-carregava-no-linux-mint-falha-no-sync-de-plugins-ipv6-quebrado-solucao-3e8b", "published_at": "2026-07-13 17:09:55+00:00", "updated_at": "2026-07-13 17:47:38.795578+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence"], "entities": ["Codex", "VS Code", "Linux Mint", "OpenAI", "ChatGPT", "GitHub", "NetworkManager"], "alternates": {"html": "https://wpnews.pro/news/codex-no-vs-code-nao-carregava-no-linux-mint-falha-no-sync-de-plugins-ipv6", "markdown": "https://wpnews.pro/news/codex-no-vs-code-nao-carregava-no-linux-mint-falha-no-sync-de-plugins-ipv6.md", "text": "https://wpnews.pro/news/codex-no-vs-code-nao-carregava-no-linux-mint-falha-no-sync-de-plugins-ipv6.txt", "jsonld": "https://wpnews.pro/news/codex-no-vs-code-nao-carregava-no-linux-mint-falha-no-sync-de-plugins-ipv6.jsonld"}}