Você abre a barra lateral do Codex no VS Code e, em vez da conversa, aparece este aviso:
Codex could not start
The extension could not start its user interface.
Desde 24/10/2026, a causa mais comum é um bug de versão da extensão openai.chatgpt, não da sua conta nem da sua rede. A saída que mais funcionou nos relatos é voltar para a versão 26.1007.21434 e desligar a atualização automática só para essa extensão. Ainda não há correção publicada: na consulta ao VS Marketplace feita em 26/10/2026, a versão mais recente continua sendo a 26.51021.22027.

O que significa "Codex could not start" no VS Code?
Significa que o processo do Codex subiu, mas a interface (o webview da barra lateral) não ficou pronta em 30 segundos. A extensão desiste e mostra o aviso. O problema está na tela, não no agente.
Para confirmar, abra o painel Output do VS Code (View > Output) e escolha o canal Codex. Nos relatos das issues #56691, #56655 e #56660, o log tem sempre a mesma assinatura: o backend inicializa e, 30 segundos depois, o erro aparece.
[CodexMcpConnection] Initialize received id=1
[CodexWebviewProvider] Webview renderer did not become ready
elapsedMs=30002 extensionVersion=26.1021.22027
reason=renderer_ready_timeout receivedWebviewMessage=false
role=sidebar stage=renderer timeoutMs=30000
Se o seu log mostra renderer_ready_timeout, é este caso. Se o erro for outro, o problema é diferente e este roteiro não se aplica.
Quais versões têm o problema?
As relatadas nas issues são a estável 26.1021.22027 e a pre-release 26.51021.22027, ambas publicadas no VS Marketplace em 23/10/2026. As anteriores, 26.1007.21434 e 26.51007.21434, são de 09/10/2026 e funcionam para a maioria.
| Versão | Canal | Situação nos relatos |
|---|---|---|
| 26.1007.21434 | Estável | Funciona. É a usada no rollback |
| 26.51007.21434 | Pre-release | Funciona |
| 26.1021.22027 | Estável | Falha com renderer_ready_timeout |
| 26.51021.22027 | Pre-release | Falha com renderer_ready_timeout |
Os relatos vêm de Windows 10 e 11, macOS Intel, Linux, Remote SSH e até Antigravity com WSL (issue #56617). Nos casos com VS Code, as versões são a 1.142 e a 1.143.
Como voltar para a versão que funciona?
Rode o comando abaixo no terminal e reinicie o VS Code. Foi o que usaram os autores das issues #56691 e #56660, e restaurou a interface nos relatos deles.
code --install-extension openai.chatgpt@26.1007.21434 --force
Se preferir pela interface: na aba Extensions, clique com o botão direito em Codex e escolha Install Another Version, conforme a documentação do VS Code. Selecione a 26.1007.21434.
Como impedir que o VS Code atualize de volta?
Sem isso, a atualização automática reinstala a versão quebrada. Na aba Extensions, clique com o botão direito em Codex e desmarque Auto Update. Isso vale só para essa extensão; as outras continuam atualizando. Quando a OpenAI publicar uma versão nova, reative e confira o log.
Atenção: o comando com @versão aparece nos relatos das issues, não na página de extensões da documentação do VS Code. Se o seu code recusar, use o Install Another Version pela interface.
E se a versão antiga também falhar?
Aí o gatilho é outro, e há dois caminhos relatados nas issues. Nenhum é oficial; são o que funcionou para quem postou.
1. Limpar o cache do webview. Um usuário no Fedora (VS Code 1.143.1) mediu que o cache do webview havia chegado a 856 MB, com arquivos de 29 versões da extensão, e que limpar resolveu sem rollback (issue #56660). Com o VS Code totalmente fechado, mova as pastas WebStorage e Service Worker para um backup. No Linux ficam em ~/.config/Code; no Windows, em %APPDATA%\Code; no macOS, em ~/Library/Application Support/Code.
# Linux (com o VS Code fechado)
mv ~/.config/Code/WebStorage ~/.config/Code/WebStorage.bak
mv ~/.config/Code/"Service Worker" ~/.config/Code/"Service Worker.bak"
A primeira abertura depois disso demora mais (cerca de 24 segundos no relato) enquanto o cache se reconstrói. Como é backup, dá para desfazer movendo as pastas de volta.
2. Voltar o próprio VS Code para a 1.142. Um usuário no Windows 11 documentou que, com o VS Code 1.143.1, até a extensão 26.1007.21434 passou a dar timeout, e que na 1.142.0 a interface abriu em cerca de 2 segundos. Outro relato confirma o mesmo no Linux. Isso indica que a 1.143.1 também entra na equação (issues #56655 e #56691).
Por que acontece?
A causa não está confirmada pela OpenAI. Os relatos nas issues #57026 e #56655 medem uma diferença de empacotamento: o webview da 26.1021.22027 pré-carrega 3.203 arquivos (cerca de 73 MB), contra cerca de 6 arquivos JavaScript (cerca de 20 MB) na 26.51007.21434. Com tanta coisa para carregar, o prazo de 30 segundos estoura em máquinas mais lentas ou com cache cheio. É uma hipótese dos usuários, não um diagnóstico do time do Codex.
O que fazer enquanto o Codex não abre?
Se você precisa trabalhar agora, não precisa esperar a correção. A Verboo Code roda como CLI no terminal, sem webview do VS Code para travar, e com tokens ilimitados. Dá para deixar o Codex de lado até a OpenAI publicar uma versão que abra.



