aiedit esconde linhas de código do agente de IA: 5 níveis e 857 testes

O editor aiedit fecha para o agente de IA não arquivos, mas linhas específicas, e faz isso no nível do código, não por um pedido no prompt. O projeto foi escrito por um desenvolvedor iniciante: ele aprende Python desde o fim de setembro de 2026, e o código foi escrito pelo Claude sob a orientação dele. O resultado tem cerca de 11 mil linhas de código, cerca de 10 mil linhas de testes e 857 testes que passam tanto no PySide6 quanto no PyQt6. A licença é MIT, e as chamadas aos modelos são requisições HTTPS comuns, sem SDK, então funcionam Anthropic, OpenAI e qualquer servidor compatível com a API da OpenAI.

Por que arquivos ignore não protegem

A ideia nasceu das fraquezas das ferramentas existentes. A documentação do Cursor diz explicitamente que comandos de terminal e ferramentas MCP "podem ler" arquivos listados no .cursorignore. O Cline chegou a remover o .clineignore: segundo o projeto, o arquivo "nunca foi pensado como uma proibição de acesso", e os autores não querem passar uma falsa sensação de segurança. Além disso, esses arquivos só funcionam com arquivos inteiros. Se o projeto é dividido entre "a IA pode" e "a IA não pode", o agente trabalha às cegas. O aiedit mantém o projeto inteiro e fecha só pontos específicos, como a fórmula de cálculo de preço ou o trabalho com pagamentos; o resto o modelo vê e edita.

Cinco níveis e uma cadeia de cinco proteções

As linhas são fechadas direto no campo com a numeração de linhas. Os níveis de acesso são estes:

• hidden: o modelo recebe apenas um marcador como <<ai-hidden:0:5 lines>>, ou seja, sabe que há algo ali e quantas linhas são;
• interface: nomes e assinaturas sem o corpo das funções (para Python);
• readonly: todo o código fica visível, mas qualquer edição é rejeitada;
• confirm: todo o código fica visível, e as edições só valem com a aprovação do autor;
• explain: o modelo explica esse código.

Sobre os níveis, funciona uma cadeia de verificações:

• o modelo não tem terminal, apenas as ferramentas do editor (ler, buscar, editar), e as pastas fechadas simplesmente não existem para ele;
• cada edição passa por uma verificação de diff; se tocar em uma linha fechada, é rejeitada, e nada é gravado em disco sem aprovação;
• os testes e o programa rodam sob o bubblewrap, em uma cópia do projeto em que o código fechado fisicamente não existe, sem rede, sem pasta pessoal e sem chaves. Mesmo despejar todos os arquivos em base64 não revelaria nada;
• o filtro de saída procura chaves, palavras de uma lista e linhas fechadas coladas no chat, e oferece mascarar, enviar ou cancelar;
• um log local registra quais arquivos foram enviados, quantas linhas ficaram ocultas e quantos caracteres foram transmitidos, e qualquer trabalho aplicado pela IA pode ser desfeito.

Há ainda um pipeline multimodelo: um modelo escreve o código, o próprio editor roda os testes na sandbox, e um modelo de outro fabricante procura erros e brechas. Só depois disso o autor vê as mudanças, junto com o resultado real dos testes, e não com um "está tudo funcionando".

Como a proteção quebrou o código escrito pelo modelo

O autor apresenta a comparação com o Claude Code sem retoques. Em uma tarefa de "aplicativo simples em Flask", o código foi escrito pelo Claude Opus 5.5 tanto no aiedit quanto no Claude Code, mas no aiedit as edições eram verificadas também pelo GLM 5.

3, e o resultado ficou pior. A causa apareceu no log. O modelo escreveu nos testes "password": "secret123", o filtro de segredos tomou isso por uma senha real, e na sandbox a linha virou raise NotImplementedError dentro do próprio dicionário.

O arquivo deixou de ser Python válido. Das 22 execuções na sandbox, 13 falharam, e o pytest nem chegou a alcançar os testes em si. O modelo não entendeu a causa e escreveu mais seis arquivos de testes para contornar o problema.

A correção: agora só o valor é substituído, "password": "<hidden>", e a sintaxe é preservada. O autor não repetiu o teste com modelos reais; a correção foi confirmada por um teste que reproduz o caso. Com modelos locais o desempenho também é irregular: o qwen2.5-coder 7B não manteve o formato de chamada de ferramentas, e a versão 32B deu conta de tarefas simples, mas não concluiu a tarefa com vários arquivos em 14 passos.

A leitura do código revelou ainda duas brechas, ambas já corrigidas. Quando um arquivo era renomeado ou copiado fora do editor, as zonas se perdiam; agora o código fechado é reconhecido por hashes de linhas. Já o projeto instalado no próprio .venv via pip install . ficava lá por inteiro, e um comando na sandbox podia lê-lo; por isso, essas cópias agora ficam ocultas.

Onde está o limite da proteção e o que aproveitar

O autor lista as limitações com franqueza. O filtro só pega o que consegue comparar: padrões de chaves, palavras de uma lista e linhas fechadas coladas literalmente; um segredo reescrito com outras palavras passa. Uma assinatura como calc_discount_for_client_x() na zona interface já revela o sentido.

Tudo o que não está fechado vai para o provedor do modelo. Uma cópia modificada do código fechado o editor não reconhece. Os hashes em *.

aimarks.json não usam salt, então uma linha curta como rate = 0.15 pode ser descoberta por força bruta, e esses arquivos não devem ser publicados em repositório aberto.

A sandbox funciona plenamente no Linux; no macOS ela é experimental e não foi testada em um Mac de verdade; no Windows, só via WSL.

A conclusão prática para equipes que liberam agentes em código comercial: a proteção deve ficar na camada de ferramentas, não no texto do prompt. Tirar o terminal do agente, usar uma sandbox com cópia sem segredos, verificar edições por diff e filtrar o que sai oferecem garantias verificáveis. O efeito colateral também é visível: quanto mais agressivo o mascaramento, maior a chance de quebrar a validade do código, e os logs de requisições se tornam a principal ferramenta de depuração. O código está disponível no GitHub e no GitFlic, e o autor pede que lhe enviem formas de contornar a proteção.