É tentador avaliar um agente de código pelo que ele faz depois de receber uma tarefa: ler arquivos, propor mudanças, executar testes e explicar o resultado. Três alterações integradas ao repositório aberto do Codex nas últimas horas chamam atenção para uma etapa anterior. Antes de tocar no código, a ferramenta precisa saber se a máquina oferece condições para o trabalho e se os caminhos usados para conversar com o usuário respeitam os limites de acesso definidos.

O codex doctor passou a verificar espaço em disco e características do volume, ganhou diagnósticos para produtos de proteção de endpoint e o editor externo passou a guardar seu buffer fora de diretórios graváveis pelo ambiente restrito. As três mudanças foram integradas ao main; isso não significa, por si só, que já estejam presentes em toda versão distribuída.

O fio comum é mais importante que cada opção isolada. O ambiente deixou de ser apenas o palco onde o agente roda. Ele virou parte das condições que determinam se a execução é confiável.

O disco cheio também é uma falha do agente

A primeira mudança acrescenta ao codex doctor a medição do espaço disponível tanto em CODEX_HOME, onde o Codex mantém seu estado, quanto no diretório de trabalho ativo. O relatório emite aviso abaixo de 5 gibibytes (GiB) e trata menos de 1 GiB como falha.

Antes, um erro causado por falta de espaço podia aparecer longe de sua origem: na instalação de uma dependência, na criação de um arquivo temporário ou durante um build. O agente enxergaria a operação que falhou, mas não necessariamente a condição sistêmica que tornou várias operações frágeis ao mesmo tempo. O diagnóstico transforma essa condição em evidência explícita.

No Windows, a mesma atualização informa se o repositório está em um Dev Drive confiável. Um Dev Drive é um volume voltado a cargas de desenvolvimento, com integração específica ao sistema de arquivos e à proteção do Windows. O relatório não promete que mover o projeto resolverá qualquer problema; ele identifica a configuração e oferece orientação quando o volume ativo não tem essa propriedade.

A consequência prática é simples. Uma equipe pode executar o diagnóstico no início de uma investigação e separar defeitos do projeto de limitações do host. Isso reduz a chance de corrigir código para compensar um disco exaurido ou uma configuração inadequada da estação.

Segurança que interfere precisa aparecer no relatório

O segundo acréscimo procura produtos de proteção de endpoint no macOS e no Windows. Esse tipo de software observa processos, arquivos e comportamentos para bloquear ameaças. A mesma vigilância pode interferir em ferramentas de desenvolvimento que criam muitos processos, leem árvores extensas ou executam binários recém-compilados.

O novo diagnóstico reconhece CrowdStrike Falcon, BeyondTrust Privilege Management, Microsoft Defender, SentinelOne e Jamf Protect. Quando encontra um produto e não consegue confirmar as exclusões relevantes para o Codex, emite um aviso com orientação específica. O resultado também distingue inspeção completa, parcial e indisponível; a ausência de detecção não vira recomendação de mudança por si só.

Essa distinção evita dois atalhos ruins. O primeiro seria concluir que toda lentidão vem do agente. O segundo, igualmente perigoso, seria recomendar que a proteção fosse desligada. O relatório cria uma terceira via: identificar a interação e pedir que as exclusões sejam verificadas conforme a política do ambiente.

Em uma empresa, isso pode mudar a conversa entre desenvolvimento e segurança. Em vez de um relato vago de que a ferramenta está lenta, o diagnóstico fornece o nome do produto detectado e o estado da inspeção. A decisão de alterar uma política continua humana e administrativa, mas passa a partir de uma evidência melhor.

O texto do usuário não deve cair em qualquer pasta temporária

A terceira mudança cuida de uma fronteira menos visível. Quando alguém abre o compositor do Codex em um editor externo, o texto atual precisa ser gravado em um arquivo temporário para que outro programa possa editá-lo. Esse buffer pode conter instruções, trechos de código ou informações que ainda nem foram enviadas ao modelo.

Agora, o Codex procura criar esses arquivos em um diretório protegido chamado editor. Ele tenta o diretório configurado do Codex, o diretório padrão e, por fim, uma alternativa no espaço de trabalho. Candidatos que se sobreponham às raízes graváveis pela política restrita são rejeitados, assim como caminhos que cheguem ao destino por links simbólicos. Se não houver local protegido, a abertura do editor falha de forma explícita. Políticas com escrita irrestrita preservam o comportamento compatível com esse nível de permissão.

O risco não está no editor externo em si. Ele aparece quando um buffer sensível é colocado numa área que outra parte da sessão restrita pode modificar. Um link simbólico torna o problema ainda mais sutil: o caminho parece estar fora da zona gravável, mas resolve para dentro dela. Validar o destino real impede que o nome da pasta funcione como uma falsa barreira.

Na prática, essa regra protege a integridade da conversa. Um comando executado no ambiente restrito não deve conseguir reescrever silenciosamente o texto que o usuário está prestes a enviar só porque ambos compartilham uma pasta temporária conveniente.

Diagnóstico não é permissão

As três alterações formam uma arquitetura útil porque mantêm papéis diferentes. O diagnóstico observa disco, volume e proteção de endpoint; ele não altera políticas do sistema. O isolamento do editor aplica a política de escrita já definida; ele não cria uma nova autorização. Em ambos os casos, a ferramenta passa a dizer com mais precisão quando o ambiente não sustenta a ação esperada.

Esse limite merece atenção. Um relatório mais detalhado não torna a máquina segura, e um diretório protegido não garante que todo dado da sessão esteja isolado. As mudanças cobrem condições específicas, com testes para limiares de disco, falhas de inspeção, múltiplos produtos, raízes graváveis, aliases e links simbólicos. Não são uma certificação geral do host.

Ainda assim, há uma mudança de maturidade. Agentes costumam ser apresentados como sistemas que conseguem fazer mais passos sozinhos. Uma definição operacional melhor inclui a capacidade de reconhecer quando não deveriam começar, quando o ambiente pode distorcer o resultado e onde um dado intermediário precisa ficar fora de alcance.

Autonomia não começa na primeira edição. Começa no instante em que a ferramenta examina as condições da máquina, respeita as fronteiras existentes e transforma uma limitação invisível em uma razão verificável para parar.