Anderson LimaSoftware Engineer & Architect
16 de octubre de 2026
6 min de lectura
38 visualizaciones
Três camadas no lemon-code: o que nunca roda, o que depende do modo de permissão e o que sempre passa por você
English summary: lemon-code's three guardrail layers: a destructive blocklist that no mode can disable, permission modes that set autonomy, path-based approval checks and secret masking, with stronger executor containment still proposed.
Publicado: 28 de outubro de 2026
Tempo de leitura: 9 min
Série: lemon-code em 30 dias, parte 5 de 13
A flag --yolo da CLI seleciona bypassPermissions, o modo mais permissivo. Ela pula prompts de permissão, mas a blocklist segue ativa: se o modelo propuser rm -rf ~, a resposta é não.
Essa recusa não vem do modelo nem de um prompt pedindo cuidado. Vem de uma regra em código que nenhum modo de permissão desliga. Este post mostra como o lemon-code organiza os guardrails em três camadas e por que a ordem delas importa.
--yolo seleciona bypassPermissions.plan é só leitura; dontAsk nega ações que precisariam de aprovação.Imagine um prédio comercial. Na portaria há uma lista de coisas que não entram de jeito nenhum, com ou sem crachá. Depois vem o crachá, que define em quais andares você circula. E para entrar na sala do cofre, alguém precisa abrir a porta com você.
No agente é igual:
A portaria é a primeira camada. Ela fica antes de tudo, então nenhum crachá passa por cima.
A primeira camada é uma lista de padrões com motivo. O código do lemon-code tem esta forma:
// blocklist destrutiva mínima (reescrita e simplificada)
const DESTRUCTIVE: Array<{ pattern: RegExp; reason: string }> = [
{ pattern: /\brm\s+-rf\s+\/(\s|$)/, reason: "apagar a raiz" },
{ pattern: /\brm\s+-rf\s+(~|\$HOME)(\s|$)/, reason: "apagar o home" },
{ pattern: /\bmkfs\b/, reason: "formatar partição" },
{ pattern: /\bdd\b.*\bof=\/dev\/(sd[a-z]|hd[a-z]|nvme\d|disk\d)\b/i, reason: "gravar em dispositivo de bloco" },
];
export function isDestructive(command: string) {
const hit = DESTRUCTIVE.find((e) => e.pattern.test(command.trim()));
return hit ? { blocked: true, reason: hit.reason } : { blocked: false, reason: "" };
}
console.log(isDestructive("rm -rf ~")); // { blocked: true, reason: "apagar o home" }
console.log(isDestructive("rm -rf ./dist")); // { blocked: false, reason: "" }
Repare que a função não recebe o modo. Ela não tem como ser relaxada por configuração, e isso é proposital.
Productos gratuitos y de pago para convertir ideas en una base que puedas lanzar.
13 productos disponibles
nextjs · boilerplate
Boilerplate de API em Python com FastAPI, organizado em Clean Architecture (router, service, repository e adapters por módulo). Inclui autenticação JWT com hashing bcrypt, MongoDB, testes com pytest e cobertura, Dockerfile e docker-compose para subir localmente, e documentação Swagger/OpenAPI automática. Repositório de origem privado; snapshot técnico verificado antes da publicação.
Ver producto
react · boilerplate
Base React Native para apps iOS y Android con Expo, Clean Architecture, MVVM, Firebase y módulos nativos. Referencia técnica de VaiDeFut, con distribución pública en Google Play y un flujo de publicación para iOS documentado.
Ver producto
nextjs · boilerplate
Kit gratuito y open source para comenzar con agentes de código en Claude Code, Codex, Gemini, Copilot y OpenCode. El repositorio público confirma una licencia MIT.
Ver producto
nextjs · boilerplate
Base AI-first white-label para lanzar productos SaaS con Next.js, chat, RAG, memoria, tenants y documentación. El snapshot verificado documenta Supabase, no MongoDB; la limitación está explícita. MongoDB, Redis y RabbitMQ requieren una integración/configuración compatible.
Ver producto
nextjs · boilerplate
Edición avanzada de una base white-label y multi-tenant AI-first para acelerar productos con Next.js, chat, RAG, memoria y documentación. El snapshot verificado no demuestra una capa Ultra distinta; la limitación y los cambios de provider, cache y colas quedan transparentes.
Ver producto
nextjs · boilerplate
Base white-label y multi-tenant para convertir una idea en un SaaS AI-first con Next.js, chat, RAG, memoria y seguridad documentada. El snapshot verificado usa Supabase; el nombre identifica el repositorio de origen. Los límites de provider, cache y colas son explícitos; Redis y RabbitMQ son integraciones configurables.
Ver producto
react · portfolio
Una contribución única para apoyar contenido técnico gratuito, investigación y la continuidad de proyectos relevantes publicados por Anderson Lima. Tú eliges el valor; no es una suscripción.
Ver producto
react · boilerplate
Starter React gratuito para crear una suite de pruebas confiable desde el primer commit con Vitest, Testing Library, Playwright, Vite, TypeScript, Zustand, React Query, MirageJS y PWA. El repositorio no declara una licencia SPDX; revisa sus términos antes del uso comercial.
Ver producto
react · portfolio
Monorepo público en React, TypeScript y Vite para explorar una biblioteca de componentes con lenguaje visual inspirado en interfaces nativas. El README actual es breve y no declara una licencia SPDX; trátalo como preview gratuito.
Ver producto
nextjs · saas
Boilerplate SaaS AI-first con Next.js, Supabase, Stripe y provider routing para avanzar desde el primer prompt hasta un despliegue real más rápido. Los cambios de IA, datos, email, cache y colas son explícitos; Redis y RabbitMQ son integraciones configurables.
Ver producto
react · saas
Starter React + TypeScript para SaaS multi-tenant con Firebase, Atomic Design, temas, PWA, pantallas de producto, MirageJS y chat Gemini extensible a otros providers. Valida requisitos de producción, costes e integraciones antes de publicar.
Ver producto
react · boilerplate
Starter React público con TypeScript, Zustand, React Query, Tailwind CSS, PWA e integraciones de IA documentadas. El repositorio no declara una licencia SPDX; revisa sus términos antes del uso comercial.
Ver producto
nextjs · saas
Landing SaaS para Next.js, TypeScript y Tailwind CSS con SEO, temas, i18n, PWA y puntos de integración para auth, Stripe e IA. Una base clara para dejar atrás la pantalla en blanco y dar forma a tu propuesta.
Ver productoContinúa explorando temas similares
Eu pagava API para tarefas que o Claude Code ou o Codex, já logados na minha máquina, resolveriam. A regra CLI-first do lemon-code cabe em quatro linhas de precedência.
Meu agente escolhia o modelo e eu não sabia por quê. Hoje cada escolha vem com uma linha como 'anthropic score 71.5 (risk +20, order +50)'. Este post mostra como chegar nisso.
O lemon-code tem seis ADRs com o número 0049, todas criadas no mesmo dia. Esse erro ensina mais sobre memória de projeto com vários agentes do que qualquer ADR bem numerada.
Un checklist práctico para validar seguridad, costos, evaluaciones y observabilidad antes de llevar tu app con IA a producción.
Templates probados en producción, usados por desarrolladores. Ahorra semanas de setup en tu próximo proyecto.
A DESTRUCTIVE_BLOCKLIST cobre operações catastróficas ou irreversíveis: apagar a raiz ou o home, chmod 777 recursivo na raiz, mkfs, dd gravando em dispositivo de bloco, e DROP DATABASE ou DROP TABLE sem alvo específico. Vale até em bypassPermissions.
Uma blocklist por regex nunca é completa. Ela não substitui sandbox. O papel dela é pegar o erro grosseiro e barato de detectar, aquele que um modelo confuso pode produzir às três da manhã numa missão autônoma.
O modo define quanta autonomia o agente tem:
| Modo | Comportamento |
|---|---|
default | pede permissão para ações sensíveis |
acceptEdits | aceita edições dentro do projeto, pergunta antes de comandos arriscados |
plan | só leitura: ler, listar, buscar; escrita e execução negadas |
dontAsk | não pergunta; o que exigiria aprovação é negado automaticamente |
bypassPermissions (--yolo na CLI) | pula prompts de permissão; a blocklist destrutiva continua ativa |
Dois modos merecem destaque. O plan é o que uso para explorar um repositório desconhecido: o agente lê sem alterar arquivos. dontAsk não é uma aprovação automática: ações que pediriam confirmação são negadas. Na CLI, a flag --yolo seleciona bypassPermissions.
Algumas ações passam por você conforme o modo e a regra aplicada: escrita fora da raiz do projeto, comandos sensíveis e operações de Git como push. O menu oferece aprovar uma vez, para a sessão, permanentemente ou negar.
O workspace entra nessa decisão: caminhos fora da raiz e diretórios protegidos podem acionar o fluxo de aprovação. Isso é uma checagem de caminho, não isolamento do processo inteiro.
Guardrail de execução não basta se a chave de API aparece no log. O lemon-code tem duas defesas:
[REDACTED] no terminal e na UI.Arquivos de configuração com credenciais recebem permissão 600 em sistemas POSIX; a tentativa é best-effort.
Parte das checagens de caminho já existe. A ADR 0024, ainda proposta, descreve contenção mais forte no executor: um workspace jail e regras explícitas para diretórios protegidos como .git/hooks. A blocklist e as aprovações reduzem riscos, mas não equivalem a um sandbox de processo.
Se você quer o modelo de ameaça completo para execução de código gerado por agente, escrevi sobre isso em Sandbox para agentes que executam código.
Guardrail bom é uma pilha em que a camada mais dura fica na frente. A blocklist não depende de modo, o modo define a autonomia e a aprovação cuida do que sobra. Nenhuma delas depende de o modelo se comportar bem.
Na sexta, o assunto muda de código para memória: como uso ADRs para manter vários agentes alinhados no mesmo projeto.
Se o seu time está liberando agentes de código com acesso ao ambiente local e quer revisar o modelo de permissões, é um trabalho que faço na LEMON.DEV.