[NOVA]: Este é o OpenClaw Daily. Eu sou a NOVA.

[ALLOY]: E eu sou o ALLOY. Hoje vamos começar com o OpenClaw v2026.5.7, porque esta versão muda a forma como operadores veem publicação, estado de cron, configuração de canais, autorização, entrega, voz, roteamento de WhatsApp e aprovações do Codex antes de passarmos para sandboxes de agentes JavaScript e endurecimento de runtime do Gemini CLI. ...

[NOVA]: A versão oferece aos operadores novas formas de verificar se publicação, cron, canais, auth, entrega, voz, memória e aprovações estão realmente funcionando. A publicação no ClawHub agora retentará falhas transitórias de instalação de dependências, mantém publicações de plugins que passam no preview avançando quando uma célula de preview falha, e verifica cada versão de pacote esperada após a publicação. O JSON de cron agora expõe o status calculado diretamente. O list de canais agora é focado em canais em vez de misturar detalhes de auth de modelo. O dispatch inline de skill de auto-reply agora passa pelos hooks de autorização antes da chamada de ferramenta. As ferramentas Tavily resolvem credenciais com suporte SecretRef do snapshot de config do runtime ativo. Alvos de canal do Discord com prefixo de provider agora são roteados como envios de canal em vez de tentativas enganosas de mensagem direta. Essa é a forma da versão: menos suposições ocultas, menos caches desatualizados, menos falsos sucessos e mais contratos explícitos com o operador.

[ALLOY]: OpenClaw v2026.5.7 Torna Publicação, Canais, Cron, Auth, Memória, Entrega, Voz, WhatsApp e Aprovações do Codex Mais Observáveis e Seguras Começando com publicação de release e plugins. Uma versão de manutenção não deveria deixar operadores se perguntando se um plugin foi realmente publicado em todos os lugares que deveria chegar. A v2026.5.7 adiciona tratamento de retry para falhas transitórias de instalação de dependência do CLI do ClawHub, mantém um plugin publicável quando uma célula de preview falha mesmo que o preview tenha passado, e verifica cada versão de pacote esperada do ClawHub após a publicação. Esse passo final de verificação é o importante. Um pipeline de publicação não está completo quando um comando sai; está completo quando as versões de pacote esperadas estão visíveis onde os instaladores downstream vão buscá-las.

[NOVA]: Isso importa para um ecossistema de plugins porque publicações parciais são piores que falhas limpas. Um pacote pode estar disponível em um lugar, faltando em outro, ou publicado na versão errada. Operadores então perseguem erros de instalação que parecem problemas de configuração local mas são realmente problemas de distribuição de release. A verificação pós-publicação transforma o processo de release em um loop de reconciliação: declare o conjunto de pacotes esperado, tente a publicação, e verifique se o estado do registro corresponde. Se não corresponder, a falha fica visível na hora da manutenção em vez de ser descoberta pelos usuários.

[ALLOY]: A superfície do modelo da OpenAI recebe uma adição direcionada: openai/chat-latest é suportado como uma substituição explícita direta de API key para testar o alias mutável do ChatGPT Instant API sem mudar o modelo padrão estável. A frase-chave é substituição explícita. Um alias mutável é útil para testar comportamento da faixa instant-chat atual, mas é um mau padrão para agentes em produção porque seu snapshot de modelo subjacente pode mudar. Mantê-lo atrás de um ID de modelo explícito permite que construtores testem o alias enquanto preservam padrões estáveis para jobs agendados, workflows de produção e avaliações reprodutíveis.

[NOVA]: Cron fica mais fácil de automatizar. cron list --json e cron show --json agora incluem status calculado, então ferramentas externas podem ler estados disabled, running, ok, error, skipped ou idle sem reimplementar a derivação de status do OpenClaw. Esta é uma boa mudança de contrato de API. Se um CLI fornece JSON para máquinas, o JSON deve incluir o estado que humanos veem. Caso contrário, cada dashboard, monitor e script wrapper tem que reengenharia reversa do status a partir de timestamps, campos de último erro, flags de enable e marcadores de execução. Isso cria automação inconsistente e alarmes falsos.

[ALLOY]: A inspeção de canal também ganha um contrato mais limpo. openclaw channels list agora é apenas canais, adiciona --all para canais bundled e catalog, renderiza estados installed, configured e enabled, e move detalhes de auth e uso de modelo para openclaw models auth list, openclaw status e openclaw models list. A separação é importante porque prontidão de canal e autenticação de modelo são domínios operacionais diferentes. Um canal do Slack ou Discord pode estar instalado mas desabilitado, configurado mas sem permissões, ou habilitado mas não saudável atualmente. Auth de modelo pertence a credenciais de provider e seleção de runtime. Misturar esses em um comando torna mais difícil para automação responder perguntas simples.

[NOVA]: Os limites de segurança são apertados em vários lugares. Handlers de comandos nativos agora honram aplicação de owner. Memória Ativa requer escopo admin para toggles de memória global. Auto-reply bloqueia dispatch de skill inline através de hooks de autorização before-tool-call. Esses são todos fixes de autorização em superfícies que podem mudar estado do sistema. Comandos nativos podem executar caminhos de controle privilegiados. Toggles de memória global podem afetar o que sessões futuras lembram. Skills inline podem acionar ferramentas de um caminho de auto-reply, onde o usuário pode não estar assistindo cada passo interno. O release empurra essas ações de volta através de checks de autorização explícitos.

[ALLOY]: O fix de dispatch de skill inline merece destaque. Sistemas de skills são convenientes porque permitem que um agente rute uma tarefa para comportamento empacotado. Mas se auto-reply pode dispatchar uma ferramenta de skill inline sem passar pelos hooks de autorização before-tool-call, então o caminho conveniente se torna o caminho mais fraco. O design certo é que cada ponto de entrada de ferramenta, seja invocado por um turno de chat visível, uma skill inline, um plugin ou um auto-reply em background, flua através do mesmo hook de política antes da execução. Isso dá aos administradores um lugar para implementar comportamento de allow, deny, prompt, log ou rate-limit.

[NOVA]: Credenciais ganham um fix similar de limite de runtime. Ferramentas dedicadas tavily_search e tavily_extract agora resolvem credenciais do snapshot de config do runtime ativo, então chaves de API exec SecretRef-backed não chegam às ferramentas não resolvidas. Sistemas SecretRef só funcionam se cada ferramenta lê secrets através da mesma visão de runtime resolvida. Se uma ferramenta recebe o marcador literal não resolvido, a falha parece credenciais ruins mesmo que o secret exista. Pior, desenvolvedores podem contornar isso hardcodando uma chave. Resolver do snapshot ativo mantém config por-run, SecretRefs e credenciais de ferramentas alinhadas.

[ALLOY]: Caminhos de instalação de plugins gerenciados ficam mais robustos também. OpenClaw agora usa o mesmo shell de lifecycle npm POSIX absoluto para operações npm de install, rollback, repair e uninstall de plugins gerenciados que atualizações de pacotes staged. O modo de falha aqui é sutil: um shell PATH restrito pode quebrar cleanup ou rollback mesmo se o caminho de install original funcionar. Usar o mesmo shell de lifecycle absoluto através de install e repair reduz drift de ambiente. Operadores deveriam poder confiar que rollback usa as mesmas suposições de toolchain que install.

[NOVA]: Correção de sessão e contexto recebe atenção. Sessões de Gateway limpam snapshots de skills em cache durante /new e sessions.reset, então sessões de canal de vida longa reconstroem listas de skills visíveis após mudanças de skills. Motores de contexto de agentes invalidam views de contexto montadas em cache quando histórico fonte encolhe ou assembly falha, impedindo que histórico pré-reset desatualizado seja reutilizado. Esses são bugs de invalidação de cache, mas o impacto visível ao usuário é severo. Se um reset não limpa o snapshot de skills, o agente pode anunciar capacidades desatualizadas. Se uma view de contexto sobrevive a um encolhimento de histórico, o modelo pode ver estado antigo de conversa após um reset.

[ALLOY]: Compaction ganha um guard de limite de modelo. Tokens de reserva de resumo são clamped ao limite de output de cada modelo para que compaction de alto contexto não solicite mais valores max_tokens inválidos. Este é um problema prático multi-modelo. Um motor de contexto pode planejar uma reserva de resumo grande, mas o modelo selecionado pode não ser capaz de emitir tantos tokens. Se a solicitação sair de qualquer forma, compaction falha no limite do provider. Clampar tokens de reserva aos limites de output do modelo transforma uma solicitação inválida em um plano de resumo limitado.

[NOVA]: A semântica de entrega fica mais honesta. Entrega de agente agora reporta deliverySucceeded=false quando entrega outbound retorna sem resultado de adapter, então caminhos de entrega claimados ou vazios não se disfarçam mais como envios bem-sucedidos. Execuções isoladas de cron também falham entrega implícita de announce antes da execução do modelo quando delivery.channel=last não tem rota anterior, então jobs recorrentes não gastam tokens antes de bater em um erro permanente de alvo de entrega. Ambas mudanças seguem o mesmo princípio: não execute trabalho caro se a rota de output é impossível, e não reporte sucesso quando nenhum adapter confirmou entrega.

[ALLOY]: O parsing de alvo do Discord ganha um fix concreto para mensagens de agentes cross-channel. Alvos com prefixo de provider como discord:channel:<id> agora são parseados como envios de canal em vez de alvos legados de mensagem direta do Discord. Isso previne que chamadas de agent mensagem(action="send") cross-channel enroutem IDs de canal em falhas enigmáticas de Canal Desconhecido. Namespaces importam aqui. Um alvo de canal com prefixo de provider não é um user id, e uma camada genérica de messaging deveria preservar essa intenção até o adapter.

[NOVA]: O endurecimento do Telegram abrange autorização e liveness. Telegram agora honora accessGroup:* sender allowlists para DMs, grupos, comandos nativos e autorização de callback antes de aplicar verificações de ID de sender numérico. O watchdog de polling permanece atrelado à liveness de getUpdates para que chamadas não relacionadas do Bot API outbound não consigam mascarar um poller inbound wedged. Esse segundo fix é um problema clássico de health-check. Um bot ainda pode enviar mensagens enquanto seu loop de polling inbound está preso. Se chamadas outbound resetarem o watchdog, o sistema parece saudável mesmo que não consiga receber input do usuário.

[ALLOY]: Operações de voz melhoram no Discord. channels capabilities e channels status --probe agora auditam permissões de canal de voz do Discord, incluindo alvos de auto-join, então permissões de Connect, Speak e Read Message History faltantes aparecem antes do /vc join. A captura de voz também é menos picotada: a graça de silêncio pós-fala padrão se estende a 2.5 segundos, voice.captureSilenceGraceMs está disponível para sessões barulhentas, e o prompt de output falado é apertado em torno de fragmentos de STT ao vivo. Agentes de voz vivem ou morrem na segmentação de turnos. Pouca graça de silêncio corta falantes. Graça demais torna o agente preguiçoso. Tornar a graça configurável dá aos operadores um knob de tuning para ruído de sala e estilo de fala.

[NOVA]: Os fixes do WhatsApp são operacionalmente específicos mas importantes. Envios proativos de número de telefone agora são roteados através de mapeamentos forward de LID do Baileys quando disponíveis, então contatos endereçados por LID recebem mensagens do agente em vez de criar ghost chats apenas de sender. Auto-replies de diretiva MEDIA: com caption agora enviam uma vez em vez de emitir uma mensagem de media vazia antes do reply de media com caption. Ambos são exemplos de correção de adapter. Provedores de messaging frequentemente têm múltiplas formas de identidade e primitivas de media. A plataforma de agente precisa mapeá-las corretamente ou usuários veem mensagens duplicadas, faltantes ou fantasma.

[ALLOY]: O comportamento de aprovação do Codex muda de uma forma que deveria reduzir fadiga de aprovação sem contornar revisão. Nos modos de aprovação do Codex, OpenClaw para de instalar o hook nativo de PermissionRequest do pre-guardian por padrão, permitindo que o revisor do Codex aprove comandos seguros antes do OpenClaw superficializar uma aprovação. Ele lembra decisões de allow-always para payloads nativos de PermissionRequest do Codex idênticos dentro da janela de sessão ativa, e solicitações de aprovação de plugin validam e renderizam suas decisões allow reais para que UIs de aprovação nativas como Telegram não possam oferecer ações desatualizadas. O detalhe a explicar é sequenciamento: deixe o revisor interno lidar com comandos seguros, superficialize aprovações quando necessário, e certifique-se de que as ações de UI correspondam ao conjunto de decisões allow atuais.

[NOVA]: A compatibilidade com provedores e mídia também recebe correções. OpenClaw normaliza uploads de PNG detectados como APNG, preserva o replay de assinaturas de pensamento de tool-call do Gemini 3 com assinaturas de fallback, aceita chaves customizadas legadas __env__:VAR de provedores, e repara a sanitização de transcrições de tool-calls em snake_case. Estas são as bordas que tornam transcrições e ferramentas portáveis. Se as assinaturas de tool-call não fizerem replay, o estado do provedor pode rejeitar turns seguintes. Se a sanitização de transcrições manusear incorretamente tool-calls em snake_case, as superfícies de replay e auditoria divergirão do que realmente aconteceu.

[ALLOY]: A nota prática de lançamento é alta para operadores. A v2026.5.7 não é um recurso chamativo; é um conjunto de contratos de confiabilidade. A publicação verifica o estado do registro. Cron expõe o status computado. Canais e autenticação de modelo são separados. Skills inline passam pela autorização. SecretRefs resolvem em runtime. Os caches de contexto invalidam após o reset. A entrega falha antes de gastar tokens. As permissões de voz e o tempo de captura são visíveis. As aprovações do Codex se alinham com as decisões reais. Estas são as mudanças que tornam um sistema de agente menos misterioso quando roda o dia todo.

[NOVA]: OpenAI Agents JS v0.9 a v0.11 Transformam Sandboxes em Manifestos de Workspace, Limites de Runtime, Agendamento de Ferramentas e Fronteiras de Artefatos O SDK de Agents da OpenAI para JavaScript tem se movido rápido esta semana, e a mudança mais importante é a superfície do agente sandbox. Agentes sandbox construem sobre o Agent, Runner e fluxo de execução existentes, mas adicionam workspaces persistentes, manifestos de workspace, sessões sandbox, capabilities, snapshots, memória e suporte a resume. Em termos práticos, esta é a diferença entre um agente que pode chamar uma função e um agente que pode trabalhar em um ambiente de computador controlado ao longo do tempo.

[ALLOY]: A abstração central é o Manifesto. Um manifesto descreve o que o workspace do agente contém: arquivos e diretórios sintéticos, arquivos e diretórios locais, repositórios Git, variáveis de ambiente, usuários, grupos, permissões, montagens e locais de saída. Isso transforma a configuração do sandbox em um contrato de workspace declarativo. Em vez de uma tarefa dizer "de alguma forma dê a este agente um repo e um lugar para escrever artefatos," o manifesto diz exatamente o que está montado, onde aparece, quais arquivos são graváveis e quais caminhos externos são permitidos.

[NOVA]: Isso importa porque agentes de arquivos e comandos precisam de fronteiras. Se um agente pode inspecionar arquivos, executar comandos, aplicar patches e gerar artefatos, o sandbox tem que definir o que está no escopo. Um workspace persistente é poderoso para tarefas de longo horizonte porque o agente pode continuar do estado anterior, mas persistência também significa que o estado pode acumular. Snapshots e comportamento de resume permitem que desenvolvedores decidam quando preservar, restaurar ou descartar esse estado. A questão operacional se torna: quais arquivos são entradas de tarefa, quais são saídas geradas e quais são memória persistente entre execuções?

[ALLOY]: A v0.11.0 adiciona uma mudança na fronteira de artefatos que é fácil perder, mas importante. A materialização de código fonte local do sandbox agora mantém LocalFile.src e LocalDir.src dentro do baseDir de materialização, a menos que o caminho fonte esteja coberto por Manifest.extraPathGrants. O diretório base é o diretório de trabalho atual do processo SDK quando o manifesto é aplicado. Fontes relativas resolvem a partir desse diretório. Fontes absolutas já devem estar dentro dele ou sob uma grant explícita. Isso fecha um problema de fronteira de artefato local.

[NOVA]: A implicação de migração é direta. Se um aplicativo copia intencionalmente arquivos host confiáveis de fora do diretório base para um workspace sandbox, agora tem que declarar isso com uma grant de caminho extra. Este é um contrato melhor. Faz a diferença entre "o agente pode ler caminhos host arbitrários porque um caminho fonte apontava para lá" e "o aplicativo concedeu explicitamente este diretório externo, possivelmente apenas leitura, com uma descrição." Para sistemas de agentes que lidam com dados de clientes, repositórios proprietários ou arquivos adjacentes a credenciais, grants explícitos são o padrão correto.

[ALLOY]: O modelo padrão do SDK mudou na v0.10.0 de gpt-4.1 para gpt-5.4-mini quando nenhum modelo é definido. Isso afeta agentes e execuções que dependiam de padrões implícitos. Como o novo padrão é um modelo GPT-5, as configurações de modelo padrão implícitas agora incluem padrões GPT-5 como reasoning.effort="none" e verbosity="low". A recomendação para desenvolvedores é simples: agentes em produção devem definir o modelo explicitamente. Padrões são úteis para exemplos e protótipos, mas comportamento do agente, custo, latência, esforço de raciocínio e verbosidade não devem mudar apenas porque uma dependência foi atualizada.

[NOVA]: Limites de turns se tornam explícitos. maxTurns=null pode desabilitar o limite de turns de execução do Agents SDK, enquanto mantém o padrão em DEFAULT_MAX_TURNS, atualmente dez, quando a configuração é omitida. Isso é uma válvula de segurança em runtime. Um limite rígido de turns previne loops descontrolados e custos surpresa. Desabilitar o limite pode ser necessário para fluxos de trabalho de longo horizonte, mas deve ser combinado com outros controles: timeouts de tempo real, listas de ferramentas permitidas, limites de orçamento, checkpointing e visibilidade de progresso. A distinção útil é que omitido significa padrão seguro; null significa que o desenvolvedor intencionalmente removeu o limite.

[ALLOY]: O agendamento de ferramentas também se torna mais controlável. toolExecution.maxFunctionToolConcurrency em RunConfig controla a concorrência de execução de ferramentas de função local do lado do SDK. Isso é separado do ModelSettings.providerSide.parallelToolCalls. Essa separação importa. O modelo pode ter permissão para propor múltiplas chamadas de ferramenta em paralelo, mas o runtime local ainda precisa decidir quantas executar de uma vez. Uma ferramenta de sistema de arquivos, ferramenta de banco de dados, ferramenta shell e ferramenta HTTP têm diferentes efeitos colaterais e perfis de recurso. A concorrência local é uma política de agendamento de runtime, não apenas uma preferência de geração de modelo.

[NOVA]: O nomeação de ferramentas MCP ganha uma opção de avoidedor de colisão. O SDK pode incluir o nome do servidor MCP nos nomes das ferramentas, alinhando-se com o SDK Python. Isso previne conflitos quando múltiplos servidores MCP expõem ferramentas com o mesmo nome local. Sem prefixos de servidor, dois servidores diferentes podem ambos expor search, read ou query. O agente então vê nomes de ferramentas ambíguos, e os logs se tornam mais difíceis de auditar. Nomes com prefixo de servidor tornam o namespace de ferramentas mais explícito, o que é especialmente importante quando agentes se conectam a múltiplos servidores de ferramentas internos e externos.

[ALLOY]: A v0.11.0 também muda o modelo padrão do RealtimeAgent para gpt-realtime-2. Os padrões realtime não são cosméticos. Um modelo realtime afeta latência de áudio, alternância de turnos, comportamento de transcrição, expectativas de barge-in e qualidade de interação de voz. Se um produto usa RealtimeAgent sem fixar um modelo, atualizar o SDK pode mudar o comportamento realtime subjacente. Novamente, a recomendação é fixar padrões de produção e testar novos modelos realtime sob condições de áudio representativas antes de movê-los para sessões voltadas para o cliente.

[NOVA]: A série de lançamento também inclui correções que mostram onde runtimes de agente falham. A v0.9.1 preserva a identidade de agente de nome duplicado na serialização de estado de execução, reconcilia chamadas de função em stream quando execuções gerenciadas pelo servidor abortam, e evita replay de IDs de itens de conversa do assistente. A v0.10.1 restaura o histórico de sessão quando a substituição de compactação de resposta falha e valida políticas de aprovação MCP hospedadas. Estas são correções de máquina de estado. Sistemas de agente têm estado local, estado de servidor, deltas em stream, substituição de compactação e política de aprovação. Se esses divergirem, o próximo turno pode fazer replay do item errado, perder histórico ou aprovar a ação errada.

[ALLOY]: O resumo prático para desenvolvedores JavaScript é tratar o Agents SDK como um runtime, não apenas um wrapper em torno de chamadas de modelo. Defina manifestos de workspace restritamente. Use extraPathGrants para caminhos host de propósito. Fixe modelos de produção. Decida se os limites de turnos devem permanecer no padrão, ser aumentados ou desabilitados com outros guardrails. Defina a concorrência de ferramentas local baseada em efeitos colaterais. Prefixe nomes de ferramentas MCP quando múltiplos servidores estão conectados. Teste mudanças de modelo realtime como mudanças de comportamento de produto, não apenas atualizações de dependência.

[NOVA]: Gemini CLI v0.42 Nightlies Fortalecem Bordas de Runtime de Agente: Avaliações de Segurança Shell, Corridas de Aprovação, Filas de Compressão, Problemas de OAuth e Patches de Auto Memory Os nightlies de 6 e 7 de maio do Gemini CLI são úteis porque mostram o trabalho unglamoroso de runtime necessário para agentes de linha de comando. As mudanças não são um único lançamento de modelo; são uma lista de casos extremos em torno de aprovação, segurança shell, compressão de contexto, falhas de streaming, OAuth, nomeação de sandbox, Auto Memory e saída não interativa. Estes são exatamente os lugares onde agentes CLI se tornam frágeis.

[ALLOY]: Comece com aprovações. As correções do servidor A2A resolvem uma condição de corrida de aprovação de ferramenta, melhoram o relatório de status e resolvem uma corrida na espera de conclusão de ferramenta. Em um runtime de agente, aprovação é uma máquina de estados. Uma chamada de ferramenta é proposta, aprovação é solicitada, uma decisão humana ou de política chega, a ferramenta executa ou é negada, e o runtime relata conclusão. Se o sistema relata status antes do resultado da aprovação ser commitado, ou espera o sinal de conclusão errado, a UI pode mostrar uma ferramenta como concluída enquanto ainda está pendente, ou executar após um caminho de negação deveria ter parado.

[NOVA]: As avaliações de segurança de comandos shell são uma adição forte. Ferramentas shell são poderosas porque permitem que agentes inspecionem arquivos, executem testes, instalem dependências e operem fluxos de trabalho de desenvolvedor. São perigosas pela mesma razão. Uma suíte de avaliação de segurança shell dá aos mantenedores uma forma de testar se o modelo e runtime identificam corretamente comandos arriscados, redirecionamentos, operações destrutivas de arquivo, exposição de credenciais e tentativas de escape de sandbox. A parte importante é que a segurança é avaliada como comportamento, não apenas documentada como política.

[ALLOY]: Os nightlies também adicionam saída JSON para AgentExecutionStopped em modo não interativo. Isso importa para CI e scripts wrapper. Uma TUI humana pode mostrar um estado parado em prosa; automação precisa de um objeto estruturado. Se execuções não interativas param por causa de uma política, limite, erro ou estado de aprovação, a saída JSON permite que sistemas chamadores distingam uma parada limpa de um crash ou timeout. Agentes CLI cada vez mais rodam dentro de jobs agendados e sistemas de orquestração, então semântica de terminal estruturada faz parte da superfície do produto.

[NOVA]: A compressão de contexto recebe uma correção de enfileiramento: mensagens podem ser enfileiradas durante a compressão. Compressão é necessária porque sessões longas de agente excedem limites de contexto, mas também é um perigo de concorrência. Se um usuário envia uma mensagem enquanto o runtime está comprimindo o histórico, o sistema tem que decidir se bloqueia a entrada, descarta, appenda à contexto antigo ou enfileira para o contexto comprimido. Enfileirar preserva a intenção do usuário enquanto permite que o gerenciador de contexto termine uma reescrita coerente. Sem isso, corrupção de chat ou turns perdidos se tornam prováveis.

[ALLOY]: O CLI também retenta erros ERR_STREAM_PREMATURE_CLOSE. Execuções de agente em streaming dependem de conexões de longa duração através de saída de modelo, progresso de ferramentas e renderização de terminal. Um fechamento prematuro pode ser uma falha transitória de rede ou transporte em vez de uma falha lógica. Retentar cuidadosamente pode tornar o sistema mais robusto, mas o runtime deve evitar duplicar efeitos colaterais. O padrão seguro é retentar caminhos de stream idempotentes ou pré-execução e ser mais conservador uma vez que uma ferramenta tiver mutado estado.

[NOVA]: Várias correções são sobre ambientes headless e não padronizados. A CLI previne um travamento silencioso durante a autenticação OAuth em Linux headless. Ela rejeita IDs de projeto numéricos em GOOGLE_CLOUD_PROJECT. Ela melhora a experiência do MCP list em pastas não confiáveis. Estas são correções de qualidade operacional. Muitos agentes rodam em máquinas remotas, containers, workers de CI ou servidores sem navegador. Falhas de autenticação e resolução de projeto precisam falhar com status acionável, não travar esperando por uma UI que não existe.

[ALLOY]: O comportamento do sandbox recebe pequenas mas importantes mudanças. A CLI randomiza nomes de containers do sandbox e permite redirecionamento nos modos YOLO e AUTO_EDIT sem sandboxing. Nomes de containers randomizados reduzem colisões quando múltiplas execuções rodam no mesmo host. O comportamento de redirecionamento importa porque sintaxe de shell é parte do trabalho normal do desenvolvedor: redirecionar saída para arquivos, fazer piping de logs e escrever patches. Mas qualquer mudança em torno do redirecionamento também precisa de avaliação de segurança porque redirecionamento pode sobrescrever arquivos ou exfiltrar conteúdo. É por isso que evals de segurança de shell e mudanças de comportamento de shell pertencem à mesma discussão.

[NOVA]: Auto Memory ganha um allowlist de patches privados mais rigoroso e documentação mais clara stating que Auto Memory propõe atualizações de memória e skills. Memória persistente é útil apenas se as atualizações forem delimitadas e revisáveis. Um allowlist de patches de memória controla quais tipos de atualizações de memória privada podem ser aplicadas automaticamente. Sem esse limite, um agente pode persistir fatos sensíveis, incorretos ou excessivamente amplos. Com um limite muito rígido, a memória se torna inútil. O modelo operacional correto é proposta, escopo, allowlist e revisão.

[ALLOY]: O lançamento de 7 de maio também move a explicação de ferramentas do thought stream para o conteúdo da chamada de ferramenta. Isso pode parecer uma limpeza de UI, mas afeta privacidade e observabilidade. Thought streams e conteúdo de chamada de ferramenta têm públicos diferentes e regras de retenção em muitos sistemas. Se uma explicação de ferramenta pertence à chamada de ferramenta, colocá-la lá torna os logs de auditoria mais claros e evita misturar a justificativa de ferramenta visível ao usuário com canais de raciocínio internos. Runtimes de agente precisam desses limites de conteúdo para permanecerem consistentes.

[ALLOY]: As correções de approval-race são especialmente importantes para servidores agent-to-agent. Quando um agente pede a outro runtime para fazer um trabalho, o lado solicitante pode ver apenas um stream de status. Se esse stream mostra approved, denied, running e completed na ordem errada, o código de orquestração pode fazer suposições inseguras. Um servidor A2A robusto trata approval, execução, cancelamento e conclusão como estados separados com transições duráveis.

[NOVA]: Os evals de segurança de shell também devem ser lidos como infraestrutura de regressão, não apenas política. Uma vez que um agente CLI suporta redirecionamento, edições de arquivo, gerenciadores de pacotes e modos sandbox, os mantenedores precisam de exemplos que provem que o runtime percebe comandos destrutivos, redirecionamento de saída perigoso, leitura de credenciais e sintaxe de shell confusa. Caso contrário, a segurança depende de revisão informal e quebra quando o modelo ou prompt muda.

[ALLOY]: A correção da fila de compressão é outro ponto de confiabilidade do mundo real. Sessões longas frequentemente comprimem o histórico exatamente quando o usuário ainda está ativo. Colocar input na fila durante a compressão preserva a ordem das rodadas: terminar o resumo, anexar a mensagem em fila ao novo contexto e continuar. Descartar ou criar uma corrida com esse input faria a CLI parecer assombrada porque a próxima mensagem do usuário seria interpretada contra a memória errada da sessão.

[NOVA]: A recomendação prática para operadores do Gemini CLI é observar essas nightlies como sinais de hardening de runtime. Máquinas de estado de approval precisam de testes de race. Ferramentas de shell precisam de evals de segurança. Compressão precisa de input em fila. Streaming precisa de regras de retry que evitem efeitos colaterais duplicados. OAuth precisa de modos de falha headless. Patches de memória precisam de allowlists. Execuções não interativas precisam de estados JSON. Estas não são polishing opcional para um agente CLI; são a diferença entre um terminal de demo e uma superfície de automação confiável.

[NOVA]: Vamos tornar a checklist do operador concreta. Para implantações do OpenClaw, o primeiro item da checklist após este lançamento é verificação de publicação. Se um plugin alega enviar múltiplos pacotes, o job de release deve comparar os nomes e versões dos pacotes pretendidos contra o resultado do registry. Isso protege instaladores, mas também protege o mantenedor, porque o incidente aponta para o estado de distribuição ao invés de um relatório vago do usuário sobre uma instalação falhou.

[ALLOY]: Segundo, trate cron JSON como a interface de monitoramento. Um dashboard não deve fazer scrape do mesmo texto que um humano lê. Ele deve ler status, última execução, próxima execução, estado de habilitado e estado de erro diretamente. Uma vez que o status é calculado pela CLI, wrappers não precisam de regras concorrentes para saber se um job está ocioso, pulado, desabilitado ou falhou. Menos interpretações independentes significa menos falsos alertas.

[NOVA]: Terceiro, separe a saúde do roteamento da saúde do modelo. Uma rota de Discord, Telegram, WhatsApp ou Slack pode ser configurada enquanto uma chave de modelo está faltando, e um modelo pode ser autenticado enquanto um canal está desabilitado ou com permissão errada. A limpeza do listing de canais facilita preservar essa distinção. Ela também facilita para os docs de suporte dizer, verifique os canais aqui, verifique a autenticação do modelo ali, depois verifique o status global para a imagem combinada do runtime.

[ALLOY]: Quarto, para memória e skills, assuma que sessões de vida longa têm visualizações desatualizadas a menos que o runtime prove que invalida elas. Snapshots de skills são úteis porque evitam reconstruir listas de capacidades a cada rodada. Caches de contexto são úteis porque montar contexto pode ser caro. Mas ambos são perigosos após reset, reparo ou redução de histórico. As correções de invalidação de cache deste lançamento são um lembrete de que resets devem limpar não apenas o histórico de chat visível, mas também artefatos derivados do runtime.

[NOVA]: Quinto, entrega deve ser um preflight quando possível e um resultado reportado depois. Um cron job sem última rota de entrega deve falhar antes da execução do modelo. Um caminho de envio sem resultado de adapter não deve se tornar um sucesso fingido. Isso é especialmente importante para agentes agendados, porque ninguém está assistindo a janela de chat quando a falha acontece. Os logs e campos de status têm que dizer a verdade.

[ALLOY]: Para OpenAI Agents JS, a checklist é diferente. Comece pinsando modelos e modelos de realtime em produção. Depois escreva manifests como se um revisor de segurança vai ler, porque eventualmente alguém vai. Declare diretórios locais intencionalmente. Use grants de path extra com moderação e descreva por que existem. Decida quais saídas são artefatos, quais arquivos são estado de workspace gravável e quais arquivos do host são inputs somente leitura.

[NOVA]: Depois ajuste os limites de runtime. Um limite padrão de dez rodadas é um trilho de segurança; desabilitá-lo é uma decisão de design. Se max turns é null, adicione um timeout de wall-clock, controle de orçamento e reporte de progresso. Se ferramentas de função local podem rodar concurrently, classifique-as por efeito colateral. Ferramentas de busca somente leitura geralmente podem paralelizar. Instalação de pacotes, escritas em banco de dados, mutações de filesystem e comandos de shell merecem agendamento mais rigoroso.

[ALLOY]: Nomeação de MCP é outro item de higiene de produção. Prefixar nomes de servidor em nomes de ferramentas pode parecer ruidoso, mas previne que o agente e os logs confundam a ferramenta de busca de um servidor com a ferramenta de busca de outro servidor. Em uma demo pequena, nomes curtos parecem melhores. Em um ambiente de produção com docs internos, tickets, busca de código, ferramentas de browser e ferramentas de dados de clientes, colisões de namespace se tornam problemas de auditoria.

[NOVA]: Para Gemini CLI, a checklist começa com comportamento não interativo. Se um agente CLI vai rodar em automação, estados parados precisam de JSON. OAuth precisa falhar claramente quando nenhum navegador está disponível. Retries de streaming precisam evitar efeitos colaterais duplicados. Compressão precisa preservar input do usuário em fila. Esses são requisitos tediosos até o agente rodar dentro de CI, um shell remoto ou um job agendado.

[ALLOY]: Segurança de shell merece sua própria linha. A questão não é se ferramentas de shell são úteis; claramente são. A questão é se o runtime pode distinguir inspeção de mutação, redirecionamento seguro de sobrescrita destrutiva, e comandos normais de desenvolvedor de comandos de risco de credencial ou sandbox. Evals de segurança transformam isso em uma superfície testável. Eles deixam os mantenedores pegarem regressões quando prompts, modelos ou comportamento de parsing de shell mudam.

[NOVA]: A recomendação mais ampla em todas as três histórias é projetar para o momento depois da demo. Uma vez que agentes publicam pacotes, rodam cron jobs, entram em canais de voz, editam arquivos e chamam ferramentas, o produto não é mais apenas uma interface de chat. É um ambiente operacional. Ambientes operacionais precisam de contratos de status, hooks de autorização, limites explícitos de filesystem, estados de approval duráveis, erros estruturados e caminhos de recuperação.

[ALLOY]: E o melhor sinal nesses lançamentos é que essas superfícies tediosas estão recebendo atenção de produto. Verificação de publicação, resolução de SecretRef, invalidação de contexto, manifests de sandbox, grants de path extra, filas de compressão e evals de segurança de shell não são capacidades de modelo de headline. São as partes que decidem se uma plataforma de agente pode ser confiada quando ninguém está supervisionando.

[NOVA]: Um detalhe final de implementação: cada uma dessas salvaguardas deve produzir um artefato que um humano possa inspecionar depois. Um resultado de verificação de registro, um status JSON de cron, um payload de decisão de aprovação, um manifesto de sandbox e um objeto JSON de execução parada são todos evidências. Eles permitem que um mantenedor reconstrua o que o agente acreditou, o que o runtime permitiu, quais ferramentas rodaram e para onde a saída deveria ir.

[ALLOY]: Essa camada de evidências é o que transforma operações de agentes de intuição para engenharia. Se uma automação falha, você não deveria ter que perguntar se o modelo alucinou, se faltava a rota, se a credencial não foi resolvida, se o contexto estava obsoleto, se o sandbox leu demais, ou se a UI de aprovação ofereceu a ação errada. O sistema deveria estreitar essa busca para você.

[ALLOY]: O resumo prático do EP047 é operacional: o OpenClaw v2026.5.7 torna o estado do sistema mais visível e seguro em publicação, cron, canais, memória, entrega, voz, mensagens e aprovações. O OpenAI Agents JS mostra como agentes em sandbox estão se tornando runtimes de manifesto de workspace com concessões de caminhos explícitos, limites de turnos, concorrência de ferramentas e namespaces MCP. O Gemini CLI mostra as bordas de runtime que importam quando agentes de linha de comando rodam em fluxos de trabalho reais: corridas de aprovação, segurança de shell, filas de compressão, retries de transporte, vivacidade OAuth e escopo de patch de memória. Para construtores, a questão não é apenas o que o agente pode fazer; é quais fronteiras, status e caminhos de recuperação existem quando ele faz o trabalho.

[NOVA]: Obrigado por ouvir o OpenClaw Daily. Os shownotes e links de origem estão em Toby On Fitness Tech ponto com, e voltamos em breve.