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.