Codex CLI 0.147.0 estreia plugins e autoaprovação com guardrails
Dante Testa
09/08/2026 · 11 min de leitura · 55 visualizações
O que chegou no Codex CLI 0.147.0
O Codex CLI 0.147.0, publicado pela OpenAI em 7 de agosto de 2026, amplia três partes centrais do trabalho com agentes de programação: extensões reutilizáveis, decisões de permissão e integração com servidores MCP. A versão introduz plugins portáteis, o sinalizador --approve-for-me e suporte opcional à especificação MCP 2026-07-28. Também reforça isolamento, redação de segredos e confiança explícita em projetos locais desconhecidos.
Para quem pratica Vibe Coding, a mudança mais importante não é um comando isolado. O Codex passa a organizar melhor capacidades que antes ficavam espalhadas entre skills, configurações, conectores e servidores. Ao mesmo tempo, oferece mais autonomia para revisar pedidos de aprovação. Isso economiza interação manual, mas aumenta a importância de configurar o ambiente antes de iniciar uma tarefa longa.
Esta matéria separa o que a versão realmente entrega, o que continua dependendo de decisão humana e como testar a atualização sem transformar conveniência em permissão ampla.
Plugins portáteis tornam o ambiente reproduzível
Segundo as notas oficiais, o Codex 0.147.0 pode instalar plugins portáteis e pesquisar em catálogos locais, pessoais, de workspace e remotos. A documentação da OpenAI define plugin como um pacote reutilizável que pode reunir skills, conectores ou ambos. Um pacote também pode declarar servidores MCP, hooks, extensões de navegador e modelos de tarefas agendadas.
Essa composição resolve um problema recorrente. Uma equipe costuma ter instruções em um diretório, ferramentas externas configuradas em outro arquivo e conhecimento operacional guardado na cabeça de poucas pessoas. Quando alguém monta um ambiente novo, cada parte precisa ser reencontrada. O plugin oferece uma unidade de distribuição mais clara: intenção, instruções e acesso a ferramentas viajam juntos, dentro das políticas do ambiente.
No Codex CLI, o navegador é aberto com /plugins. A documentação orienta instalar a partir de um marketplace configurado e iniciar uma nova sessão antes de usar as capacidades adicionadas. Esse detalhe evita uma expectativa errada: a instalação não deve alterar silenciosamente o conjunto de ferramentas de uma conversa já em andamento.
Há uma limitação relevante. Na documentação consultada em 9 de agosto de 2026, plugins não estavam disponíveis na extensão de IDE. O catálogo pode ser usado em superfícies compatíveis, como o aplicativo desktop e o CLI, mas não se deve presumir paridade entre todas as interfaces do Codex.
Plugin não é sinônimo de confiança automática
Um plugin pode conter algo simples, como instruções de revisão, ou algo poderoso, como um servidor MCP capaz de consultar serviços externos. Também pode incluir hooks, que executam comandos em pontos do ciclo de vida. Por isso, a pergunta correta antes de instalar não é apenas “isso ajuda?”, mas “quais capacidades entram no ambiente e em quais momentos elas podem agir?”.
Um checklist mínimo de avaliação inclui:
- origem do marketplace e identidade do publicador;
- arquivos e instruções incluídos no pacote;
- servidores MCP e conectores que serão habilitados;
- domínios de rede necessários;
- hooks e comandos acionados automaticamente;
- credenciais solicitadas e forma de armazenamento;
- escopo de leitura e escrita no workspace;
- mecanismo de atualização e possibilidade de fixar uma versão.
O 0.147.0 traz correções que acompanham esse novo poder. As notas mencionam endurecimento do isolamento de plugins, recusa de acesso à rede quando uma atualização de política falha e prevenção contra a travessia de links simbólicos durante a instalação. O lançamento também exige confiança explícita para projetos locais desconhecidos antes de usar credenciais. Esses controles reduzem risco, mas não substituem a revisão do pacote.
Para uma equipe, o caminho mais seguro é começar com um catálogo de workspace pequeno e versionado. Cada plugin deve ter dono, finalidade e revisão registradas. Catálogos remotos podem ampliar descoberta, porém também ampliam a superfície de fornecedores, versões e permissões que precisam ser governadas.
O que o --approve-for-me realmente muda
O novo sinalizador --approve-for-me habilita aprovações submetidas a revisão automática. Isso é diferente de conceder uma autorização irrestrita ao agente. O próprio nome da funcionalidade nas notas, “automatically reviewed approvals”, indica que ainda existe uma decisão de política: um pedido é analisado antes de ser aceito ou recusado.
Em uma tarefa longa, o benefício é reduzir interrupções para ações rotineiras que já cabem em regras conhecidas. Por exemplo, ler arquivos dentro do repositório, executar uma suíte de testes aprovada ou gravar em uma pasta de build pode ser compatível com a política da equipe. Uma tentativa de acessar outra pasta, usar a rede ou executar um comando destrutivo deve continuar encontrando limites mais fortes.
A qualidade dessa automação depende do contexto que o revisor recebe e das fronteiras impostas pelo sandbox. Se o ambiente permite escrita ampla e rede irrestrita, uma aprovação bem classificada ainda pode produzir efeito maior que o necessário. Se o ambiente começa restrito, a mesma revisão automática opera sobre uma superfície menor.
Uma adoção responsável começa com três camadas:
- Sandbox mínimo: conceder somente os diretórios e recursos exigidos pela tarefa.
- Política explícita: separar ações rotineiras, ações que exigem justificativa e ações proibidas.
- Auditoria posterior: revisar comandos, arquivos alterados e acessos externos ao fim da execução.
O lançamento também remove o antigo codex exec --full-auto. A orientação oficial é usar --sandbox workspace-write. A troca é significativa porque faz o operador declarar a fronteira de escrita, em vez de depender de um rótulo amplo de automação. Quem mantém scripts antigos deve procurar o sinalizador removido antes de atualizar o ambiente de produção.
MCP 2026-07-28: integração mais escalável, migração consciente
O Codex 0.147.0 adiciona suporte opcional à revisão 2026-07-28 do Model Context Protocol. Nas notas da versão, isso inclui descoberta paginada, solicitações de múltiplas rodadas e inicialização não bloqueante de servidores. O termo “opcional” importa: a atualização do CLI não obriga todos os servidores a trocar de protocolo imediatamente.
A especificação de 28 de julho muda a base do transporte. O MCP passa a operar com núcleo stateless, remove a troca initialize/initialized e deixa de usar Mcp-Session-Id como parte obrigatória do fluxo. Cada requisição carrega informações suficientes para ser encaminhada a uma instância disponível. Isso facilita balanceamento e reduz a necessidade de manter afinidade de sessão na infraestrutura.
Outra mudança útil é a Multi Round-Trip Request, ou MRTR. Um servidor pode indicar que precisa de confirmação ou de um parâmetro adicional e a chamada original é repetida com as respostas anexadas. Para agentes de programação, isso abre espaço para ferramentas que pedem confirmação dentro do próprio protocolo, como aprovar um custo, escolher um alvo ou confirmar uma operação sensível.
A revisão também permite cache em resultados de listagem e adiciona cabeçalhos para nome de método e ferramenta. Um gateway pode usar essas informações para roteamento, medição e autorização sem interpretar todo o corpo JSON. Em organizações com muitos servidores MCP, essa visibilidade ajuda a aplicar política por tipo de operação.
Há custo de migração. O núcleo stateless e a retirada de elementos antigos alteram pressupostos de clientes e servidores. A especificação mantém uma política de depreciação, mas novos projetos não devem começar dependentes de recursos marcados para remoção. Antes de ativar o protocolo no Codex, inventarie servidores, versões de SDK, autenticação e testes de integração.
Correções pequenas que evitam incidentes grandes
As notas do 0.147.0 incluem ajustes que merecem atenção mesmo fora das manchetes. O Codex passou a redigir segredos e tokens bearer completos em comandos exibidos e históricos reproduzidos. Isso reduz a chance de uma credencial aparecer em logs, capturas de tela ou artefatos de suporte.
Também foram corrigidos problemas de entrada do terminal quando o foco retorna, quando servidores MCP inicializam ou quando atalhos do Ghostty entram em cena. Para tarefas longas, uma entrada perdida pode parecer congelamento ou falta de resposta e induzir o usuário a repetir comandos. A correção melhora previsibilidade operacional.
No Windows, a versão corrige interrupção de processos em segundo plano e tratamento de caminhos. Na interface de terminal, há ajustes para caracteres japoneses, emojis, hyperlinks e posicionamento do cursor. Esses itens não ampliam a inteligência do agente, mas reduzem ruído na camada em que pessoas acompanham e interrompem ações.
Roteiro de teste antes de adotar na equipe
Uma atualização com plugins, aprovações automáticas e protocolo novo não deve ser validada apenas com “o comando abriu”. O teste precisa simular as fronteiras do trabalho real.
1. Faça o inventário do ambiente atual
Registre a versão instalada, os scripts que chamam codex exec, as regras de sandbox, os servidores MCP e as skills usadas pela equipe. Procure especificamente por --full-auto, pois o sinalizador foi removido.
2. Escolha um repositório descartável ou uma worktree
Use uma cópia isolada, sem credenciais de produção. A tarefa de teste deve incluir leitura, uma mudança simples, execução de teste e tentativa deliberada de sair do escopo. O objetivo é observar tanto o caminho permitido quanto a recusa.
3. Instale um plugin conhecido
Prefira um pacote pequeno, com arquivos legíveis e sem hooks. Abra /plugins, instale a partir do catálogo autorizado, inicie nova sessão e confirme quais skills e ferramentas ficaram disponíveis. Depois, remova ou desabilite o pacote e verifique se o ambiente volta ao estado esperado.
4. Teste aprovações com ações de risco diferente
Compare uma leitura dentro do workspace, uma escrita permitida, um acesso de rede e uma tentativa fora do diretório. Registre o pedido apresentado, a decisão automática e o efeito real. Se ações sensíveis forem aceitas sem justificativa suficiente, reduza permissões antes de ampliar uso.
5. Ative MCP novo somente com servidor compatível
Valide descoberta, paginação, solicitação de entrada e reinicialização. Um cliente compatível não corrige um servidor que ainda assume sessão obrigatória. Mantenha um caminho de retorno para a revisão anterior durante o período de teste.
6. Compare resultados e esforço humano
Meça interrupções, tempo total, recusas corretas, aprovações indevidas e necessidade de intervenção. A meta não é zerar perguntas. É reduzir perguntas repetitivas sem perder controle sobre ações materialmente diferentes.
O que a versão não autoriza concluir
As notas não dizem que qualquer plugin é seguro, que toda aprovação automática será correta ou que servidores antigos migrarão sem alteração. Também não tornam o Codex autônomo fora das permissões que recebe. O agente continua limitado por sandbox, política, ferramentas expostas e contexto fornecido.
Da mesma forma, suporte a um protocolo não garante que todas as integrações de terceiros implementem a mesma revisão no mesmo dia. Equipes devem verificar cliente, servidor e SDK, além de observar autenticação e depreciações.
A melhor novidade é a composição com limites
O Codex CLI 0.147.0 aproxima extensibilidade e governança. Plugins facilitam empacotar capacidades; a revisão automática reduz interrupções; o MCP atualizado melhora integração e escala. O ganho aparece quando essas peças são combinadas com catálogo confiável, sandbox mínimo, política verificável e trilha de auditoria.
Para quem usa Vibe Coding em projetos reais, a recomendação prática é simples: atualize primeiro em ambiente isolado, escolha um plugin pequeno, teste uma tarefa representativa e tente romper deliberadamente os limites definidos. Uma automação confiável não é a que nunca pede ajuda. É a que avança sozinha dentro do combinado e para quando a ação muda de natureza.
