A página estava visível, mas o Codex não conseguia controlar o navegador. Dois problemas no mesmo computador —uma conexão ausente com o navegador e uma página de erro antiga— exigiram medidas diferentes. Este artigo explica a ordem das verificações e o que realmente se recuperou.
Navegador integrado, integração com o Chrome e pesquisa na web
Pedir ao Codex para “pesquisar no navegador” nem sempre usa o mesmo mecanismo. Identificar qual recurso falha e o que ele não consegue fazer ajuda a evitar mudanças desnecessárias nas configurações.
| Recurso | O que acessa | O que verificar |
|---|---|---|
| Navegador integrado do aplicativo de desktop | Uma página aberta ao lado do chat | O Codex consegue obter essa aba, ler seu conteúdo e clicar em um link? |
| Integração por extensão, como a do Chrome | Abas do navegador habitual | A extensão está conectada e consegue acessar a aba desejada? |
| Pesquisa na web | Resultados de pesquisa e conteúdo obtido de páginas | Consegue pesquisar e obter informações? Isso é diferente de verificar cliques em uma página. |
A documentação oficial do navegador da OpenAI informa que o Codex no aplicativo de desktop pode abrir o navegador integrado, clicar, digitar e inspecionar páginas. Não afirma que a CLI ou a extensão do IDE tenham, por si só, um navegador integrado. A primeira distinção é onde você usa o Codex.
O navegador integrado tem um perfil separado do navegador habitual. Ver a extensão do Chrome instalada não comprova que o controle do navegador integrado esteja conectado. Da mesma forma, o navegador integrado funcionar não compartilha automaticamente as abas já abertas no Chrome. Explicação da OpenAI sobre o navegador e seu perfil
Priorizamos o navegador integrado nesta investigação e usamos o Chrome para testar outra rota de conexão. Evitamos reunir exibição da página, conexão com o navegador e operações de um site em um único resultado de “funciona ou não”.
A página abre, mas o Codex não encontra o navegador
A investigação começou quando o Codex passou a informar que não conseguia mais realizar operações de navegador que antes funcionavam. O navegador estava habilitado nas configurações do aplicativo e a extensão do Chrome aparecia instalada. Também era possível abrir páginas no navegador integrado.
Porém, o inventário da interface de controle não conseguia obter nem o navegador integrado nem o Chrome. O único destino visível era uma superfície separada de MCP Apps. A tela que o usuário via não correspondia aos destinos de controle disponíveis para o Codex.
A página está visível
As configurações estão habilitadas
Consegue obter a aba?
Consegue ler e clicar?
Para confirmar a recuperação, precisávamos testar se o Codex conseguia obter a aba, ler seu conteúdo e usar links, além de verificar a exibição da página.
Três sintomas a distinguir primeiro
Um problema de conexão como este exige verificações diferentes de uma falha em apenas um site. Primeiro identifique até onde a operação chega.
A solicitação vem da CLI ou da extensão do IDE
@Browser.Esse era o sintoma neste computador
Páginas públicas podem ser controladas
Faça um teste mais específico do que “corrigir o navegador”: peça para abrir uma página pública → ler um título → clicar em um link visível → voltar. Assim você não confunde uma pesquisa na web bem-sucedida com cliques funcionando no navegador.
Outro chat em que bastou recarregar para resolver
Em outro chat de desenvolvimento, permaneceu na aba uma página “Não é possível acessar esse site”, da época em que o servidor local estava parado. Mesmo após a recuperação do servidor, a tentativa do Codex de obter a aba era rejeitada porque o formato da URL não era permitido.
- O servidor para Uma página interna de erro permanece
- A aba é recarregada Retorna à página HTTP do servidor recuperado
- O Codex a lê A obtenção do conteúdo da aba existente funciona
A URL real informada pelo inventário normal de abas usava o formato data:, que contém HTML diretamente. Quando o usuário recarregou normalmente a mesma aba, a URL real voltou a HTTP e o Codex conseguiu ler títulos e botões. Não foi preciso reiniciar o aplicativo inteiro nem alterar permissões.
Isso é diferente de uma conexão com o navegador ausente do inventário. Naquele chat, verificou-se somente a leitura do conteúdo, não a entrada nem o controle do jogo. A causa interna dos erros anteriores na rota de conexão também continua indeterminada.
O que mudamos antes da recuperação
Neste computador, os dados reais do diretório principal do Codex já estavam em D:\CodexHome. O local padrão %USERPROFILE%\.codex era uma junção para D, mas as variáveis CODEX_HOME dos escopos de usuário e máquina não estavam definidas.
A OpenAI documenta CODEX_HOME como raiz de configurações, autenticação, logs, sessões, skills e estado relacionado. Aqui o usamos para testar uma referência direta ao caminho real já existente em D. Ele não é documentado como opção específica de reparo do navegador. Especificação de variáveis de ambiente da OpenAI
- Paramos o aplicativo e os processos relacionados do Codex. Após confirmar com o usuário que o trabalho nos outros chats havia terminado, fizemos o backup com esses processos parados.
- Copiamos o diretório principal e outros dados e conferimos o conteúdo. Comparamos quantidades, tamanhos e datas de modificação de cerca de 68.6GB em 445,279 arquivos, além dos hashes de 144 arquivos importantes.
- Especificamos o caminho real em D para uma única inicialização. Após encerrar totalmente a mesma versão do aplicativo, nós o iniciamos e confirmamos que o shell e a configuração de controle gerada referenciavam D.
- Testamos separadamente o navegador integrado e o Chrome. Ambos puderam ser obtidos e as operações de leitura de páginas e links funcionaram.
- Também verificamos a inicialização habitual. Após a aprovação, definimos a variável de ambiente do usuário. Uma nova instância aberta pela barra de tarefas usou as mesmas referências e passou nas mesmas operações.
O ponto importante é que não movemos primeiro o aplicativo para outra unidade. A recuperação do navegador foi confirmada antes da transferência. Houve outra falha nessa transferência posterior; portanto, este caso não sustenta usar a função de mover aplicativos do Windows como reparo do navegador.
Também não excluímos a junção nem reescrevemos manualmente a configuração do MCP. Lemos as referências da configuração gerada após a inicialização para verificar se correspondiam ao estado pretendido. A diferença entre o diretório principal e o aplicativo está em nosso registro de migração de C para outra unidade.
Operações para confirmar a recuperação
Após a recuperação, fizemos mais do que conferir se o navegador aparecia no inventário: controlamos páginas públicas. Os testes não exigiram login, compra nem envio de arquivos pelo usuário.
| Destino | Operação | Resultado |
|---|---|---|
| Navegador integrado | Ler example.com, seguir Learn more até a explicação da IANA e voltar. | Leitura, cliques, navegação e retorno funcionaram. |
| Chrome | Abrir uma página pública da IANA em uma aba de teste e seguir um link para outra explicação. | Leitura e navegação funcionaram; depois fechamos a aba de teste. |
| Inicialização habitual | Abrir pela barra de tarefas e verificar a referência a D e as operações do navegador. | As verificações também funcionaram no novo processo do aplicativo. |
Não guardamos um inventário das abas privadas existentes do Chrome como evidência do artigo. Uma nova aba de teste bastou para confirmar a recuperação. Investigar o navegador não exige coletar e-mails abertos nem sites internos de empresas.
Também verificamos o estado salvo. Os itens selecionados, incluindo 2 chats fixados, 18 projetos fixados e 63 projetos locais, coincidiam com o backup. A verificação do status de login da CLI também terminou com sucesso. A recuperação não exigiu reconstruir o histórico nem entrar novamente.
Reiniciar o aplicativo é diferente de reiniciar o PC. Verificamos a primeira situação, mas adiamos os testes após reinício do PC e futuras atualizações para um momento conveniente para o usuário. Os resultados cobrem a recuperação imediata e a inicialização normal do aplicativo.
O que evitar no início
Excluir dados do aplicativo ou perfis do navegador antes de distinguir problemas de conexão, de um site ou de armazenamento pode causar a perda de logins, configurações e evidências para comparação. Não limpamos todos os dados do navegador nem reinstalamos o aplicativo para recuperá-lo neste caso.
Restaurar antigas skills do navegador também não foi nossa solução padrão. No computador investigado, a ausência delas fazia parte da mudança para Computer Use unificado. Um arquivo antigo ausente, sozinho, não basta para identificá-lo como causa da falha.
Não usamos configurações internas não documentadas, patches no código nem substituições de executáveis. Mudar a versão poderia parecer restaurar o funcionamento, mas deixaria de ser uma comparação anterior e posterior na mesma versão, como neste caso.
Também não foi preciso relaxar progressivamente a segurança quando os acessos necessários do navegador integrado e do Chrome já estavam habilitados. Ter permissão para controlar um site é diferente de confiar em seu conteúdo. Escolha uma página de teste sem informações sensíveis nem ações com consequências importantes.
Informações a guardar se continuar falhando
Para suporte ou investigação, um registro de até onde cada operação chega ajuda mais do que um “não funciona” genérico. Aqui a diferença importante foi que as páginas eram exibidas, os destinos de controle não eram obtidos e, após a recuperação, até a navegação por links funcionou.
- A versão do aplicativo e se você usa desktop, CLI ou IDE.
- Se o sintoma afeta o navegador integrado, o Chrome ou ambos.
- Se você consegue abrir a página manualmente, se o Codex consegue lê-la e clicar.
- Se afeta apenas um site ou também páginas públicas sem login.
- Se encerrou totalmente e abriu uma nova instância e se usa outra unidade ou diretório principal personalizado.
- O horário da falha e a mensagem real. Exclua logs brutos que contenham segredos.
Ao verificar o diretório principal, diferencie o valor $env:CODEX_HOME do shell, a configuração de usuário do Windows e o valor usado pelo aplicativo em execução. Quem não usa um local personalizado não precisa imitar este caso apontando para uma pasta vazia em D.
Não conseguir abrir o histórico ou falhar só ao enviar não são necessariamente problemas de controle do navegador. Conforme a mensagem exibida, consulte também nosso artigo Codex thread not found e verificação do histórico.
Ordem de verificação baseada neste caso
Primeiro verifique onde você usa o Codex e qual navegador está envolvido. Se uma página de erro continuar após o servidor se recuperar, recarregue normalmente essa aba. Depois teste separadamente exibição, leitura e cliques em uma página pública. Se não houver conexão alguma com o navegador, salve o trabalho e considere encerrar totalmente e reiniciar o aplicativo. Em computadores com o diretório principal migrado, também pode ajudar conferir o local referenciado.
Neste computador funcionou a combinação de especificar diretamente o caminho real do diretório principal já existente em D e abrir o aplicativo após encerrá-lo totalmente. Podemos relatar a recuperação, mas não afirmar que a junção foi a única causa. Verificar mudanças reversíveis uma por vez é mais viável do que tratar transferências ou exclusão de dados como soluções universais.
Perguntas frequentes
Se vejo a página, o Codex consegue controlá-la?
Neste computador, a página estava visível, mas não podia ser obtida como destino de controle. Verifique também a leitura do conteúdo e os cliques nos links.
Instalar a extensão do Chrome corrige o navegador integrado?
O navegador integrado e a integração com o Chrome usam rotas separadas. Verifique qual falha. Também testamos cada um separadamente neste caso.
Definir CODEX_HOME sempre resolve?
Não comprovamos isso. Neste computador, especificamos o caminho real e encerramos e reiniciamos totalmente o aplicativo ao mesmo tempo; depois ele se recuperou. Isso não justifica recomendar primeiro uma migração do diretório principal em computadores cujo armazenamento não mudou.
Preciso mover o aplicativo para D para recuperar o navegador?
O navegador se recuperou antes de mover o próprio aplicativo. Transferir um aplicativo do Windows é diferente de reparar o controle do navegador.
Abrangência do registro e nomes das unidades
Neste artigo, a unidade que contém o Windows é chamada de unidade C e o destino, de unidade D. Para facilitar a leitura, os caminhos de exemplo também usam sempre D.
Este é o registro da investigação do Codex sobre os sintomas no computador do operador em 20 de outubro de 2026. O aplicativo era OpenAI.Codex 26.1013.4894.0, na mesma versão antes e depois dos testes. Como especificamos o caminho real e reiniciamos juntos, não é possível distinguir o efeito isolado de cada medida. O artigo não recomenda mudar de unidade como solução para toda falha de navegador.
