DEV Community: Josué Sevahc

Codex in VS Code would not load on Linux Mint: plugin sync failure, broken IPv6 (solution)

Josué Sevahc — Mon, 13 Jul 2026 17:13:46 +0000

Short description / summary

The Codex extension interface remained completely blank in VS Code, while the logs showed failures when synchronizing plugins with ChatGPT and GitHub. This is the complete diagnosis on Linux Mint and the steps that restored the interface.

Codex in VS Code would not load on Linux Mint: plugin sync failure, broken IPv6, and the solution

Recently, the Codex extension interface stopped loading in my VS Code installation on Linux Mint.

The main visual symptom was not a clear error message: the Codex panel simply remained blank. The extension appeared to be installed, the tab opened, but the main controls and chat area did not load.

After checking the extension logs, I found failures related to synchronizing the Codex plugin catalog with ChatGPT services and GitHub.

This post documents the diagnosis, the tests performed, and the sequence that restored the interface.

Environment

The problem occurred in the following environment:

Linux Mint 22.3
VS Code
Official Codex/OpenAI extension
Codex CLI installed locally
Connection with no proxy configured
Functional IPv4
IPv6 available on the system, but without functional external connectivity

Visual symptom

When opening the Codex tab in VS Code, the interface remained almost completely blank.

The following elements did not appear normally:

conversation history;
functional model selector;
usable prompt field;
complete session controls;
clear error messages in the interface itself.

The only way to understand what was happening was to open the extension logs.

Initial messages found

The first logs indicated a failure when accessing the remote plugin catalog:

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

Similar errors also appeared while warming the caches:

failed to warm featured plugin ids cache

failed to warm remote plugin catalog cache

failed to refresh remote installed plugins cache

The failing requests included endpoints such as:

https://chatgpt.com/backend-api/plugins/featured
https://chatgpt.com/backend-api/ps/plugins/list
https://chatgpt.com/backend-api/ps/plugins/installed

Initially, this appeared to be only a failure in the ChatGPT remote plugin catalog.

However, after disabling the remote catalog, a second and more specific message appeared.

Failure while synchronizing curated plugins from GitHub

The next log showed that Codex was also trying to synchronize a curated plugin repository from 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

The Git fallback also failed:

git ls-remote curated plugins repo failed

fatal: unable to access
'https://github.com/openai/plugins.git/':

Could not resolve host: github.com

Codex also reported that a local snapshot already existed:

skipping export archive fallback because
a local curated plugins snapshot already exists

At this point, the situation was as follows:

the interface did not load;
the ChatGPT remote catalog failed;
the curated GitHub repository was not synchronized;
there were local temporary files related to plugins;
the local Codex process remained active even after reloading the VS Code window.

Initial network diagnosis

To distinguish a general internet connection issue from a Codex-specific failure, I tested the ChatGPT endpoint directly.

IPv4 test

curl -4 -sS -o /dev/null \
  -w 'HTTP IPv4: %{http_code}\n' \
  --connect-timeout 15 \
  'https://chatgpt.com/backend-api/plugins/featured?platform=codex'

Result:

HTTP IPv4: 401

The 401 response was acceptable for this test.

The purpose was not to access authenticated content, but to confirm that:

the domain was resolved;
the TCP connection was established;
TLS worked;
the server responded.

Therefore, IPv4 was operational.

IPv6 test

curl -6 -sS -o /dev/null \
  -w 'HTTP IPv6: %{http_code}\n' \
  --connect-timeout 15 \
  'https://chatgpt.com/backend-api/plugins/featured?platform=codex'

Result:

curl: (28) Failed to connect to chatgpt.com port 443
after 15002 ms: Timeout was reached

HTTP IPv6: 000

This confirmed a second problem: the system had IPv6 configured or advertised, but the IPv6 route was not functional.

Applications that tried IPv6 before IPv4 could wait for the timeout before continuing.

Proxy verification

I also checked whether VS Code or Codex were inheriting proxy environment variables:

env | grep -iE '^(http|https|all|no)_proxy='

The command returned no values.

Therefore, there was no evidence of:

HTTP_PROXY;
HTTPS_PROXY;
ALL_PROXY;
NO_PROXY.

A proxy was ruled out as the cause.

Solution that restored the interface

The recovery involved two fronts:

temporarily disabling the plugin subsystem;
completely terminating Codex and VS Code, while removing temporary synchronization residues.

Using only Developer: Reload Window was not sufficient.

1. Disable plugins in Codex

I opened the global configuration file:

code ~/.codex/config.toml

It would also be possible to use:

nano ~/.codex/config.toml

In the [features] section, I added:

[features]
plugins = false
remote_plugin = false

If the [features] section already exists, only the two properties should be added:

plugins = false
remote_plugin = false

There must not be two [features] sections in the same TOML file.

The complete configuration was structurally as follows:

[features]
plugins = false
remote_plugin = false

This change temporarily disables:

the remote plugin catalog;
general plugin loading and synchronization.

The Codex core remains usable, but features provided by plugins remain unavailable while the flags are disabled.

2. Completely terminate Codex and VS Code

I closed the VS Code windows and terminated the remaining processes:

pkill -f codex || true

pkill -f '/usr/share/code/code' || true

The path in the second command may vary if VS Code was installed through Snap, Flatpak, or another method.

The goal was to ensure that the app-server and the extension process did not remain active in the background.

3. Remove temporary plugin clones

Next, I removed only the temporary plugin clone directories:

find ~/.codex/.tmp \
  -maxdepth 1 \
  -type d \
  -name 'plugins-clone-*' \
  -print \
  -exec rm -rf -- {} + \
  2>/dev/null

This command is restricted to directories named:

plugins-clone-*

inside:

~/.codex/.tmp

I did not delete the entire ~/.codex directory.

This was important because ~/.codex may also contain:

configurations;
authentication;
history;
sessions;
still-valid caches;
MCP definitions.

4. Open VS Code again

After the cleanup, I started VS Code again:

code

At this point, the Codex interface loaded normally.

The following elements appeared again:

chat area;
prompt field;
model selector;
reasoning level selector;
session controls;
workspace access options.

Therefore, the visual recovery happened after the combination of:

disabled plugins;
complete termination of the processes;
removal of temporary clones;
restarting VS Code.

Preventive correction for broken IPv6

Although the interface had already returned, the previous test showed that the connection's IPv6 route was unavailable.

To prevent applications from trying a broken IPv6 route before using IPv4, I configured Linux to prioritize IPv4.

I ran:

grep -q '^precedence ::ffff:0:0/96  100$' /etc/gai.conf \
  || echo 'precedence ::ffff:0:0/96  100' \
  | sudo tee -a /etc/gai.conf

The following line was added:

precedence ::ffff:0:0/96  100

This configuration does not remove IPv6 from the machine.

It changes the priority used by the system resolver, favoring IPv4-mapped addresses when both IPv4 and IPv6 are available.

I then restarted NetworkManager:

sudo systemctl restart NetworkManager

IPv4 DNS validation

I verified the resolution of the involved services:

getent ahostsv4 chatgpt.com

getent ahostsv4 github.com

getent ahostsv4 api.github.com

All three commands returned IPv4 addresses.

Copying specific IP addresses into static configurations is not recommended, because those addresses may change.

GitHub validation

I tested the GitHub API:

curl -4 -I --connect-timeout 15 https://api.github.com

Main result:

HTTP/2 200

I then tested the main website:

curl -4 -I --connect-timeout 15 https://github.com

Main result:

HTTP/2 200

Finally, I validated the exact Git operation that had failed in the logs:

git ls-remote https://github.com/openai/plugins.git HEAD

The command returned:

<commit-hash>    HEAD

This confirmed that:

the github.com domain was resolving;
HTTPS was functional;
Git could query the repository;
the ls-remote operation was no longer blocked.

What was the actual cause?

It was not possible to prove a single, isolated cause.

The evidence pointed to a combination of factors:

1. Plugin synchronization during startup

Codex attempted to load:

the remote catalog;
remotely installed plugins;
featured plugins;
the curated repository hosted on GitHub.

These operations were failing during startup.

2. Local processes still running

Reloading only the VS Code window did not completely restart the entire local Codex layer.

Explicitly terminating the processes was necessary.

3. Temporary residues

There were directories related to temporary plugin clones.

The removal was limited to the plugins-clone-* directories.

4. IPv6 without connectivity

IPv4 worked, but IPv6 ended in a timeout.

This could introduce delays and failures in applications that prioritized IPv6.

5. Apparently transient GitHub resolution failure

The log recorded:

Could not resolve host: github.com

Later, the tests with getent, curl, and git ls-remote worked.

Therefore, it would not be correct to state that there was a permanent DNS failure.

The failure may have been:

transient;
related to the previous process;
aggravated by the IPv6 route;
associated with the plugin synchronization attempt.

What was not necessary

In this case, it was not necessary to:

delete the entire ~/.codex directory;
reinstall Linux;
reinstall certificates;
change DNS servers;
remove the extension;
log in to the OpenAI account again;
delete MCP configurations;
reinstall VS Code.

Those actions would have been more invasive and could have removed valid configurations without addressing the actual cause.

How to re-enable plugins later

Disabling plugins should be treated as a controlled workaround.

After a Codex update or once the network is stable, the features can be tested again, one flag at a time.

First, test only the remote catalog:

[features]
plugins = false
remote_plugin = true

After completely restarting Codex and VS Code, check the logs.

If it remains stable, test the complete subsystem:

[features]
plugins = true
remote_plugin = true

If the interface becomes blank again, return to:

[features]
plugins = false
remote_plugin = false

This strategy helps identify whether the problem is:

in the remote catalog;
in the curated repository;
in a specific plugin;
or in the general synchronization process.

Precautions when publishing logs

Commands such as:

curl -I

may return headers such as:

set-cookie
authorization
x-github-request-id

Before publishing logs in blogs, forums, or issues, remove:

cookies;
tokens;
authentication headers;
email addresses;
unnecessary usernames;
private paths;
session IDs;
signed URLs.

For public documentation, showing the following is usually sufficient:

HTTP/2 200

or the specific error message.

Solution summary

The sequence that resolved the problem was:

code ~/.codex/config.toml

Add:

[features]
plugins = false
remote_plugin = false

Terminate the processes:

pkill -f codex || true
pkill -f '/usr/share/code/code' || true

Remove temporary clones:

find ~/.codex/.tmp \
  -maxdepth 1 \
  -type d \
  -name 'plugins-clone-*' \
  -print \
  -exec rm -rf -- {} + \
  2>/dev/null

Open VS Code again:

code

Then, as a network stabilization measure:

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

Validate:

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

Conclusion

The most misleading aspect of this problem was visual.

The extension did not display an explicit failure screen: the interface simply did not load.

The logs showed that Codex was failing during plugin synchronization operations. Recovery required temporarily disabling that layer, completely terminating the local processes, and removing temporary clones.

Separately, the tests revealed a broken IPv6 route, while IPv4 remained functional. Prioritizing IPv4 reduced the risk of further timeouts.

The main lesson was not to treat a blank interface as a simple VS Code visual failure. In this case, the problem was in the startup flow of the local Codex process and in the network dependencies triggered during plugin synchronization.

Technical references

The official documentation confirms that the VS Code extension is powered by the Codex app-server and that the CLI and extension share the ~/.codex/config.toml configuration. The configuration reference also documents features.remote_plugin, while the official repository records recent problems related to plugin synchronization and temporary plugin directories.

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

Josué Sevahc — Mon, 13 Jul 2026 17:09:55 +0000

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.

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:

a interface não carregava;
o catálogo remoto do ChatGPT falhava;
o repositório curado do GitHub não era sincronizado;
havia arquivos locais temporários relacionados aos plugins;
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:

desativar temporariamente o subsistema de plugins;
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.