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

Descrição curta / resumo

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.

Tags

#linux, #vscode, #openai, #debugging, #Codex, #Linux Mint, #VS Code, #OpenAI, #Plugins, #IPv6, #GitHub, #NetworkManager, #Troubleshooting

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

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.

Ambiente

O problema ocorreu no seguinte ambiente:

• Linux Mint 22.3
• VS Code
• Extensão oficial do Codex/OpenAI
• Codex CLI instalada localmente
• Conexão sem proxy configurado
• IPv4 funcional
• IPv6 disponível no sistema, mas sem conectividade externa funcional

Sintoma visual

Ao abrir a aba do Codex no VS Code, a interface permanecia praticamente vazia.

Não apareciam normalmente:

• histórico de conversas;
• seletor funcional de modelo;
• campo de prompt utilizável;
• controles completos da sessão;
• mensagens claras de erro na própria interface.

A única forma de entender o que estava acontecendo foi abrir os logs da extensão.

Primeiras mensagens encontradas

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.

Falha na sincronização dos plugins curados pelo GitHub

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:

1. a interface não carregava;
2. o catálogo remoto do ChatGPT falhava;
3. o repositório curado do GitHub não era sincronizado;
4. havia arquivos locais temporários relacionados aos plugins;
5. o processo local do Codex continuava ativo mesmo após recarregar a janela do VS Code.

Primeiro diagnóstico de rede

Para separar uma falha geral de internet de uma falha específica do Codex, testei o endpoint do ChatGPT diretamente.

Teste por IPv4

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:

• o domínio foi resolvido;
• a conexão TCP foi estabelecida;
• o TLS funcionou;
• o servidor respondeu.

Portanto, o IPv4 estava operacional.

Teste por IPv6

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.

Verificação de proxy

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.

Solução que restaurou a interface

A recuperação aconteceu em duas frentes:

1. desativar temporariamente o subsistema de plugins;
2. encerrar completamente o Codex e o VS Code, removendo resíduos temporários da sincronização.

Apenas usar Developer: Reload Window não foi suficiente.

1. Desativar os plugins no Codex

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 catálogo remoto de plugins;
• o carregamento e a sincronização geral dos plugins.

O núcleo do Codex continua utilizável, mas recursos fornecidos por plugins deixam de estar disponíveis enquanto as flags estiverem desativadas.

2. Encerrar completamente Codex e VS Code

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.

3. Remover clones temporários de plugins

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:

• configurações;
• autenticação;
• histórico;
• sessões;
• caches ainda válidos;
• definições de MCP.

4. Abrir novamente o VS Code

Depois da limpeza, iniciei novamente:

code

Nesse ponto, a interface do Codex carregou normalmente.

Voltaram a aparecer:

• área de conversa;
• campo de prompt;
• seletor de modelo;
• seletor de nível de reasoning;
• controles da sessão;
• opções de acesso ao workspace.

Portanto, a recuperação visual aconteceu após a combinação de:

• plugins desativados;
• encerramento completo dos processos;
• remoção dos clones temporários;
• nova inicialização do VS Code.

Correção preventiva para o IPv6 quebrado

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

Validação de DNS por IPv4

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.

Validação do GitHub

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:

• o domínio github.com estava resolvendo;
• o HTTPS estava funcional;
• o Git conseguia consultar o repositório;
• a operação ls-remote não estava mais bloqueada.

Qual foi realmente a causa?

Não foi possível provar uma causa única e isolada.

As evidências apontaram para uma combinação de fatores:

1. Sincronização de plugins durante a inicialização

O Codex tentava carregar:

• catálogo remoto;
• plugins instalados remotamente;
• plugins em destaque;
• repositório curado hospedado no GitHub.

Essas operações estavam falhando durante a inicialização.

2. Processos locais ainda ativos

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.

3. Resíduos temporários

Existiam diretórios relacionados aos clones temporários dos plugins.

A remoção foi limitada aos diretórios plugins-clone-*.

4. IPv6 sem conectividade

O IPv4 funcionava, mas o IPv6 terminava em timeout.

Isso poderia introduzir atrasos e falhas em aplicações que priorizassem IPv6.

5. Falha aparentemente transitória de resolução do GitHub

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:

• transitória;
• relacionada ao processo anterior;
• agravada pela rota IPv6;
• associada ao momento da sincronização dos plugins.

O que não foi necessário fazer

Neste caso, não foi necessário:

• apagar toda a pasta ~/.codex;
• reinstalar o Linux;
• reinstalar certificados;
• trocar o DNS;
• remover a extensão;
• refazer o login da conta OpenAI;
• apagar configurações de MCP;
• reinstalar o VS Code.

Essas ações seriam mais invasivas e poderiam eliminar configurações válidas sem atacar a causa real.

Como reativar os plugins posteriormente

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á:

• no catálogo remoto;
• no repositório curado;
• em um plugin específico;
• ou no processo geral de sincronização.

Cuidados ao publicar logs

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:

• cookies;
• tokens;
• cabeçalhos de autenticação;
• e-mails;
• nomes de usuário desnecessários;
• caminhos privados;
• IDs de sessão;
• URLs assinadas.

Para documentação pública, normalmente basta mostrar:

HTTP/2 200

ou a mensagem específica de erro.

Resumo da solução

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

Conclusão

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.

Referências técnicas

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.