O navegador aparece na lista. As abas também, com título e URL. Você pede para o agente ler a página e o retorno é este:
Cannot read properties of undefined (reading 'timeoutMs')A extensão está instalada, a conexão está de pé, e nenhuma aba é lida. Esse detalhe é o que engana: o erro não aparece na descoberta do navegador, aparece na primeira ação que encosta no conteúdo da página. Quem lê o sintoma como falta de permissão reinstala a extensão e continua exatamente no mesmo lugar.
O padrão foi reportado na #59276 em Ubuntu, na #59494 em macOS com reproduções adicionais em Windows, na #59574 na extensão do VS Code em Ubuntu e na #59662 no CLI com a extensão apontando para o Brave no Linux, entre 4 e 5 de novembro de 2026. Todas seguem abertas em 9 de novembro de 2026.
O que significa "Cannot read properties of undefined (reading 'timeoutMs')"?
Significa que a camada que executa ações no navegador recebeu um objeto sem o campo timeoutMs e tentou ler esse campo mesmo assim. O JavaScript dispara um TypeError na hora, antes de qualquer requisição sair da máquina.
Isso explica os três sinais que confundem. Não é timeout de rede, porque a falha leva milissegundos. Não é permissão negada, porque a extensão já entregou a lista de abas. E não é aba fechada, porque o erro acontece justamente quando o agente tenta usar a aba que acabou de encontrar.
Como confirmar em três chamadas que é esse erro e não outro?
Separe descoberta de ação. A descoberta funciona, a ação quebra. Se as duas quebrarem, o seu problema é outro e este texto não se aplica.
// 1. descoberta: extensão, perfil e abas
await cua.getState()
// 2. bind de uma aba que já existe
const tab = await cua.getTab(tabId, { browser })
// 3. conteúdo da aba
await tab.domSnapshot()Na #59494, o próprio autor do relato descreve o mesmo formato: o bind de uma aba HTTPS que já existe e a tentativa de snapshot devolvem o TypeError antes de qualquer conteúdo ser acessado. Numa reprodução em Windows 10, de 8 de novembro de 2026, o cua.getTab falha na hora e uma aba só devolve a URL por outro caminho, a API direta do navegador. Nessa mesma reprodução, domSnapshot(), screenshot() e um evaluate somente leitura com timeoutMs explícito falham com o mesmo TypeError, o que fecha a hipótese de valor padrão mal preenchido.
| Sinal | O que ele prova |
|---|---|
cua.getState() devolve extensão, perfil e abas com título e URL | a ponte com o navegador está viva |
cua.getTab() falha de imediato com o TypeError | o problema está na camada de ação, não na de descoberta |
domSnapshot(), screenshot() e evaluate falham igual | não é uma função específica quebrada, é a camada inteira |
| O tempo até falhar é de milissegundos | não é rede, não é carregamento de página, não é timeout |
Como resolver quando o app veio de pacote de distribuição?
Comece comparando o que está instalado com o que o repositório oferece. No relato de #59276, o app instalado era 26.1013.31256 e o repositório já tinha 26.1029.61003, com os plugins bundleados na mesma build.
apt policy chatgptA saída traz duas linhas que importam: Installed e Candidate. Se o candidato for maior que o instalado, existe versão publicada e o app não te mostrou isso.
sudo apt update
sudo apt install --only-upgrade chatgptDepois de atualizar, feche o app e abra de novo. O roteiro de verificação que passou no relato foi este, nesta ordem:
- Criar uma aba temporária e navegar para uma URL pública.
- Ler o conteúdo dessa aba.
- Clicar em um link visível, confirmar que a navegação aconteceu e ler a página de destino.
- Ler a aba que falhava antes, pelo mesmo
cua.getTab. - Fechar a aba temporária.
O relato é explícito no que não foi preciso fazer: sem reset de perfil, sem apagar cookie, sem patch de native host e sem trocar de pilha de automação.
Por que "não há atualização disponível" não significa que você está atualizado?
Porque o check de atualização responde uma pergunta mais estreita do que a que você fez. Ele compara a sua build com o que um endpoint público daquele canal anuncia, e não consulta o seu gerenciador de pacotes.
No código do codex doctor, o check updates.status monta a lista de endpoints por canal e plataforma: releases do GitHub, API do Homebrew cask, o appcast do macOS e o windows-store-update.json no Windows. O comentário do próprio arquivo diz que o check nunca executa package manager nem helper de PATH, e que alvo de update via npm aparece como não inspecionado. Não existe endpoint para pacote de distribuição Linux.
codex doctor --jsonSe a linha do updates.status disser latest version status: current version is not older, leia assim: aquele canal não anunciou nada mais novo. Não leia como: a minha instalação está em dia. No relato que destravou o problema, a mensagem de indisponível do updater do app simplesmente não era uma consulta ao repositório, e o APT já oferecia a versão seguinte.
A mesma correção serve para a extensão do VS Code?
Não. Em #59574, a extensão 26.1007.21434 lista as abas e falha ao anexar. A tentativa de atualizar para 26.1021.22027, a mais nova disponível na lista do VS Code, instala e quebra a interface do Codex, que deixa de abrir. Voltar para 26.1007.21434 devolve a interface e devolve o TypeError junto.
No Windows o padrão também reapareceu depois de atualizar: um relato de 7 de novembro de 2026 usa a build 26.1021.31345 e ainda vê o TypeError, e outro de 8 de novembro de 2026, em Windows 10 com o pacote 26.1013.4894.0, reproduz o mesmo comportamento.
| Superfície | Versão no relato | Atualizar resolveu? |
|---|---|---|
| App desktop no Ubuntu, pacote da distro | 26.1013.31256 para 26.1029.61003 | Sim, com verificação de cinco passos |
| Extensão do VS Code no Ubuntu | 26.1007.21434 para 26.1021.22027 | Não: a versão nova não abre a interface e a antiga mantém o erro |
| App desktop no macOS | conexão e listagem funcionando | Sem correção confirmada na #59494 |
| App desktop no Windows | 26.1021.31345, em 7/11/2026 | Não, o erro foi reproduzido depois |
| App desktop no Windows 10 | 26.1013.4894.0, em 8/11/2026 | Não, o erro foi reproduzido depois |
Por que o agente diz que o navegador sumiu quando ele continua lá?
Porque duas armadilhas de diagnóstico produzem o mesmo alarme falso, e as duas aparecem no acompanhamento da #59276.
A primeira é chamar uma ferramenta que não é a da extensão. Um agente tentou chrome-devtools.list_pages e recebeu Missing X server to start the headful browser. Essa integração tenta subir o próprio navegador com interface gráfica, então o erro dela não diz nada sobre a conexão da extensão que já está aberta.
A segunda é concluir ausência a partir de um inventário parcial. Outro agente procurou cua_repl dentro do ALL_TOOLS do functions.exec, não encontrou e anunciou que a ferramenta não existia. O .mcp.json do plugin de computer use declara omit_tools_from: ["code_mode", "deferred"], ou seja, a ferramenta é omitida daquele inventário de propósito. Chamando mcp__cua_repl.js direto, o navegador apareceu e a página foi lida. Não houve restart, reinstalação nem reset de perfil para resolver essa falsa recorrência.
A regra que sai disso: prova de vida é ler uma página, não listar abas. Listar abas prova só que a extensão conversa com o app.
O que não vale a pena repetir?
O relato de #59276 lista o que já tinha sido tentado antes de a atualização resolver. Tudo abaixo falhou:
| Tentativa | Resultado |
|---|---|
| Reiniciar a máquina | o erro persistiu |
| Atualizar o CLI standalone | o erro persistiu |
| Iniciar uma sessão CUA nova | o erro persistiu |
| Desabilitar e reabilitar a extensão do Chrome | o erro persistiu |
| Checar atualização da extensão do Chrome | a versão não mudou |
| Reinstalar o plugin de navegador | a descoberta voltou e a leitura falhou de novo em cerca de meio segundo |
Repare no padrão: seis tentativas mexeram em tudo menos na build do app. A recompensa veio justamente da única peça que ninguém tinha trocado.
Dá para trabalhar enquanto isso não se resolve?
Dá, dividindo o trabalho em duas pilhas. O que precisa de uma aba autenticada fica parado, porque nenhum ajuste no prompt devolve a leitura que a camada CUA não entrega. O que não precisa de navegador continua rodando normalmente no terminal, incluindo buscar a página por outro caminho e entregar o conteúdo ao agente como texto.
Antes de abrir um relato, vale registrar o que o diagnóstico já mostra: saída de cua.getState(), versão do app, versão dos plugins bundleados e o resultado de codex doctor --json. Essas quatro informações são o que separa um relato que avança de um relato que vira mais uma rodada de reinstalação.
Quando a ponte com o navegador quebra, o que decide o seu dia é quanto do trabalho continua andando sem ela. Na Verboo Code a sessão roda no terminal e o /doctor junta diagnóstico da instalação, versão, updates, sandbox e avisos de MCP na mesma tela, para você parar de adivinhar qual camada falhou. Com token ilimitado, repetir o roteiro de cinco passos depois de cada atualização não custa uma segunda tentativa paga.
