Modos de execução

Os modos de execução controlam como o agente do Cherri Code executa chamadas de ferramenta e quando o Cherri Code solicita sua aprovação.

Use-os para definir quanta autonomia o agente tem para executar comandos de shell, usar ferramentas MCP e fazer chamadas Fetch. A configuração mais segura e útil para a maioria das pessoas é Auto-review. Ela executa chamadas reconhecidamente seguras, isola comandos de shell quando possível e pede a um classificador para revisar todo o resto.

Escolha um modo

No app para desktop, acesse Configurações > Agentes > Aprovações e execução.

Como funciona o Auto-review

O Auto-review se aplica a chamadas de ferramenta de shell, MCP e Fetch. O Cherri Code verifica cada chamada nesta ordem:

Um comando de shell "pode ser executado no sandbox" quando funciona dentro das limitações de arquivos e rede do sandbox. Comandos que precisam de acesso total ao sistema, como gravações fora do espaço de trabalho ou operações privilegiadas, não podem ser executados no sandbox e vão para o classificador.

O sandboxing é uma camada adicional aos modos de execução para comandos de shell. Ele controla onde um comando de terminal compatível é executado, e não se o modo usa o classificador do Auto-review.

Quando o classificador bloqueia uma chamada, o Cherri Code pode tentar outra abordagem. Se o agente decidir que a ação faz sentido apesar da decisão do classificador, o Cherri Code mostrará uma solicitação de aprovação.

Requisitos do classificador do Auto-review

O classificador do Auto-review é executado em um modelo compacto gerenciado pelo Cherri Code. Atualmente, é Claude 4.5 Haiku ou GPT-5.4 Mini.

Os controles de acesso a modelos corporativos se aplicam. O Auto-review fica disponível quando pelo menos um desses modelos é permitido para a equipe. Bloquear todos eles desativa o Auto-review em Configurações > Agentes > Aprovações e execução, mesmo que os modos de execução da equipe o incluam. Nesse caso, os membros usam a lista de permissão.

Se o Auto-review estiver esmaecido, habilite esses modelos em Configurações da equipe → Modelos, feche o Cherri Code completamente, reabra-o e verifique Aprovações e execução novamente.

Configurando o Auto-review

Não é necessário configurar o Auto-review para que ele funcione bem. Se houver ações específicas que você sempre queira revisar manualmente, descreva-as em linguagem simples.

A maneira mais fácil de configurar isso é pedir ao agente do Cherri Code para fazer isso. Diga algo como "Quero que todo comando da AWS CLI passe por aprovação primeiro", e ele editará seu permissions.json para você.

Você também pode editar o arquivo manualmente. O Auto-review lê o permissions.json em dois locais:

Se ambos os arquivos existirem, o Cherri Code os combina. Suas instruções pessoais e as instruções do projeto serão aplicadas.

As equipes também podem definir uma configuração global do Auto-review no dashboard. Quando uma configuração de equipe é definida, ela tem prioridade, e o Cherri Code ignora os arquivos de nível de usuário e de nível de projeto.

Ambos os arquivos locais usam o mesmo schema. Cada instrução é uma frase em linguagem simples, portanto, uma solicitação como "Quero que todo comando da AWS CLI passe por aprovação primeiro" é mapeada diretamente para block_instructions:

{  "autoRun": {    "allow_instructions": [],    "block_instructions": [      "Every AWS CLI command should go through approval first.",      "Every command that modifies Kubernetes resources should go through approval first."    ]  }}

• allow_instructions descrevem ações que o Auto-review deve priorizar permitir.
• block_instructions descrevem ações que o Auto-review deve priorizar bloquear, para que o agente possa escolher outro caminho ou pedir sua aprovação.

Para saber mais sobre a criação de políticas, leia Governing agent autonomy with Auto-review.

Sandboxing

O sandboxing permite que o Cherri Code execute comandos de terminal sem conceder acesso total à máquina. Um comando em sandbox pode operar no seu projeto, mas não pode ler livremente arquivos protegidos, gravar fora dos caminhos aprovados nem se conectar a destinos de rede arbitrários.

Para uma análise técnica detalhada, leia Implementing a secure sandbox for local agents.

Alguns comandos precisam de acesso total ao sistema e ignoram o sandbox. O Cherri Code indicará quando um comando for executado fora do sandbox e solicitará sua aprovação.

Configuração do sandbox

Personalize o comportamento do sandbox com um arquivo sandbox.json:

Se ambos os arquivos existirem, o Cherri Code os mesclará, com o arquivo no nível do projeto tendo prioridade. As políticas do admin da equipe e as regras de segurança hardcoded do Cherri Code se sobrepõem a eles, portanto os arquivos locais não podem enfraquecer essas proteções.

Use o sandbox.json para controlar a política de rede, caminhos adicionais com permissão de leitura ou gravação, gravações em diretórios temporários e caches de build compartilhados. Consulte a referência do sandbox.json para ver o schema completo.

Como o sandboxing funciona na sua plataforma

Variáveis de ambiente

O Cherri Code injeta variáveis de ambiente em todos os processos შვილos em sandbox. Elas ficam disponíveis para seus scripts, ferramentas de build e automações executados dentro do sandbox.

Automação do Docker e de contêineres

Um padrão comum em regras e scripts de automação é executar contêineres Docker que precisam usar a identidade do usuário do host. Como o sandbox remapeia o UID no Linux, $(id -u) retorna o valor incorreto. Em vez disso, use as variáveis CURSOR_ORIG_*:

docker run --rm \  --user "${CURSOR_ORIG_UID:-$(id -u)}:${CURSOR_ORIG_GID:-$(id -g)}" \  -v "$PWD:/work" -w /work \  my-image build

O fallback ${CURSOR_ORIG_UID:-$(id -u)} garante que o comando também funcione fora do sandbox, onde as variáveis não estão definidas.

Acesso à rede

Escolha como os comandos de terminal em sandbox acessam a rede:

*.cloudflarestorage.com*.docker.com*.docker.io*.googleapis.com*.githubusercontent.com*.gvt1.com*.public.blob.vercel-storage.com*.yarnpkg.comalpinelinux.organaconda.comapache.orgapt.llvm.orgarchive.ubuntu.comarchlinux.orgawscli.amazonaws.comazure.combinaries.prisma.shbitbucket.orgcentos.orgcloudflarestorage.comcocoapods.orgcodeload.github.comcpan.orgcrates.iodebian.orgdl.google.comdocker.comdocker.iodot.netdotnet.microsoft.comeclipse.orgfedoraproject.orgfiles.pythonhosted.orgfonts.gstatic.comgcr.ioghcr.iogithub.comgitlab.comgolang.orggoogle.comgoproxy.iogradle.orghaskell.orghashicorp.comhex.pmindex.crates.iojava.comjava.netjson-schema.orgjson.schemastore.orgk8s.iolaunchpad.netmaven.orgmcr.microsoft.commetacpan.orgmicrosoft.commise.runnodejs.orgnpm.duckdb.orgnpmjs.comnpmjs.orgnuget.orgoracle.compackagecloud.iopackages.microsoft.compackagist.orgpkg.go.devplaywright.azureedge.netppa.launchpad.netproxy.golang.orgpub.devpublic.blob.vercel-storage.compublic.ecr.awspypa.iopypi.orgpypi.python.orgpythonhosted.orgquay.ioregistry.npmjs.orgregistry.yarnpkg.comrepo.maven.apache.orgruby-lang.orgrubygems.orgrubyonrails.orgrustup.rsrvm.iosecurity.ubuntu.comsh.rustup.rssourceforge.netspring.iostatic.crates.iostatic.rust-lang.orgsum.golang.orgswift.orgubuntu.comvisualstudio.comyarnpkg.comziglang.org

Outras proteções

Os modos de execução e o sandboxing não são os únicos controles de segurança. Estas proteções podem exigir aprovação mesmo quando um modo seria executado automaticamente:

Controles da equipe

Admins podem determinar quais modos estão disponíveis para seus usuários, além de configurar as regras de rede do sandbox para comandos de terminal e muito mais. Todas essas configurações estão disponíveis no dashboard web.

As configurações da equipe têm precedência sobre as configurações individuais e do projeto. Use-as quando quiser estabelecer uma base consistente para todos. Se você ativar o Auto-review para a equipe, mantenha permitido um dos modelos de que o classificador precisa no controle de acesso a modelos.

Registro de alterações