Modos de ejecución
Los modos de ejecución controlan cómo el agente de Cherri Code realiza llamadas a herramientas y cuándo Cherri Code te solicita aprobación.
Úsalos para decidir cuánta autonomía tendrá el agente con los comandos de shell, las herramientas MCP y las llamadas de Fetch. La configuración útil más segura para la mayoría de las personas es Auto-review. Ejecuta llamadas conocidas por ser seguras, aísla los comandos de shell cuando es posible y pide a un clasificador que revise todo lo demás.
Elige un modo
En la aplicación de escritorio, ve a Configuración > Agentes > Aprobaciones y ejecución.
| Modo | Qué se ejecuta sin pedir confirmación | Sandbox | Clasificador | Úsalo cuando |
|---|---|---|---|---|
| Auto-review | Las llamadas de la lista de permitidos se ejecutan de inmediato. Los demás comandos de shell se ejecutan en el sandbox cuando es posible. Las llamadas que no usan el sandbox pasan al clasificador de Auto-review. | Sí, para comandos de shell | Sí | Quieres menos solicitudes de aprobación, con una revisión de seguridad antes de ejecutar llamadas de mayor riesgo. |
| Lista de permitidos | Las acciones de tu lista de permitidos se ejecutan sin aprobación. Con el sandboxing activado, los comandos de shell compatibles pueden ejecutarse en el sandbox. | Opcional, para comandos de shell | No | Quieres un comportamiento determinista con un conjunto reducido de acciones repetitivas de confianza. |
| Run Everything | Todas las llamadas a herramientas se ejecutan automáticamente. | No | No | Aceptas el riesgo y no quieres solicitudes de aprobación. |
Cómo funciona Auto-review
Auto-review se aplica a las llamadas a herramientas de shell, MCP y Fetch. Cherri Code comprueba cada llamada en este orden:
Un comando de shell «puede ejecutarse en el sandbox» cuando funciona dentro de los límites de archivos y red del sandbox. Los comandos que requieren acceso completo al sistema, como las escrituras fuera del espacio de trabajo o las operaciones con privilegios, no pueden ejecutarse en el sandbox, por lo que se envían al clasificador.
El sandboxing es una capa adicional a los Modos de ejecución para comandos de shell. Controla dónde se ejecuta un comando de terminal compatible, no si el modo usa el clasificador de Auto-review.
Cuando el clasificador bloquea una llamada, Cherri Code puede probar otro enfoque. Si el agente decide que la acción tiene sentido a pesar de lo que indicó el clasificador, Cherri Code te mostrará una solicitud de aprobación.
El clasificador puede cometer errores. Puede permitir una llamada que habrías bloqueado o bloquear una llamada que habrías permitido.
Requisitos del clasificador de Auto-review
El clasificador de Auto-review se ejecuta en un modelo pequeño gestionado por Cherri Code. Actualmente, es Claude 4.5 Haiku o GPT-5.4 Mini.
Los controles de acceso a modelos de Enterprise se aplican. Auto-review está disponible cuando al menos uno de esos modelos está permitido para el equipo. Bloquearlos todos desactiva Auto-review en Ajustes > Agentes > Aprobaciones y ejecución, incluso si los modos de ejecución del equipo lo incluyen. En su lugar, los miembros usan la lista de permitidos.
Si Auto-review aparece atenuado, activa esos modelos en Ajustes del equipo → Modelos, cierra Cherri Code por completo y vuelve a abrirlo; después, vuelve a comprobar Aprobaciones y ejecución.
Configuración de Auto-review
No es necesario configurar Auto-review para que funcione bien. Si hay acciones específicas que siempre quieres revisar manualmente, descríbelas en lenguaje natural.
La forma más sencilla de configurarlo es pedirle al agente de Cherri Code que lo haga. Dile algo como "Quiero que todos los comandos de AWS CLI requieran aprobación" y editará tu permissions.json.
También puedes editar el archivo tú mismo. Auto-review lee permissions.json desde dos ubicaciones:
| Ubicación | Alcance |
|---|---|
~/.cursor/permissions.json | Se aplica a todos los directorios de proyectos de tu máquina. |
<project-dir>/.cursor/permissions.json | Se aplica a un directorio de proyecto. Confírmalo cuando el proyecto deba compartir las mismas instrucciones. |
Si ambos archivos existen, Cherri Code los fusiona. Se aplican tanto tus instrucciones personales como las del proyecto.
Los equipos también pueden definir una configuración global de Auto-review en el Panel de control. Cuando se define una configuración de equipo, tiene prioridad y Cherri Code ignora los archivos de nivel de usuario y de nivel de proyecto.
Ambos archivos locales usan el mismo esquema. Cada instrucción es una frase en lenguaje natural, por lo que una solicitud como "Quiero que todos los comandos de AWS CLI requieran aprobación" se asigna directamente a 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_instructionsdescriben las acciones que Auto-review debería priorizar permitir.block_instructionsdescriben las acciones que Auto-review debería priorizar bloquear para que el agente pueda elegir otra opción o pedirte aprobación.
Para más información sobre el diseño de políticas, consulta Governing agent autonomy with Auto-review.
Sandboxing
El sandboxing permite a Cherri Code ejecutar comandos de terminal sin darles acceso completo a la máquina. Un comando en sandbox puede trabajar en tu proyecto, pero no puede leer libremente archivos protegidos, escribir fuera de las rutas aprobadas ni conectarse a destinos de red arbitrarios.
Para conocer los detalles técnicos, lee Implementing a secure sandbox for local agents.
permissions.json determina qué llamadas ejecuta Auto-review automáticamente y cuáles revisa. sandbox.json controla a qué puede acceder un comando en sandbox, como dominios de red y rutas adicionales de lectura o escritura. No necesitas ninguno de los dos archivos para empezar.
| Acceso | Comportamiento predeterminado del sandbox para los comandos de terminal |
|---|---|
| Archivos del espacio de trabajo | Acceso de lectura y escritura dentro del espacio de trabajo. .cursorignore puede ocultar archivos al agente de programación. |
| Rutas protegidas | Cherri Code protege rutas como .git/config, .git/hooks, .vscode, .cursorignore y archivos de configuración confidenciales de Cherri Code. |
| Red | Bloqueada de forma predeterminada; tu modo de red y sandbox.json pueden habilitarla. |
| Archivos temporales | /tmp y los directorios temporales de la plataforma permiten escritura, salvo que se desactive en sandbox.json. |
Algunos comandos necesitan acceso completo al sistema y omiten el sandbox. Cherri Code indicará cuándo un comando se ejecuta fuera del sandbox y solicitará tu aprobación.
Configuración del sandbox
Personaliza el comportamiento del sandbox con un archivo sandbox.json:
| Ubicación | Alcance |
|---|---|
~/.cursor/sandbox.json | Se aplica a todos los directorios de proyectos de tu equipo. |
<project-dir>/.cursor/sandbox.json | Se aplica a un directorio de proyecto. Inclúyelo en un commit si el proyecto debe compartir las mismas reglas de sandbox. |
Si existen ambos archivos, Cherri Code los fusiona y el archivo de nivel de proyecto tiene prioridad. Las políticas de team-admin y las reglas de seguridad integradas de Cherri Code se aplican además de estas, por lo que los archivos locales no pueden debilitar esas protecciones.
Usa sandbox.json para controlar la política de red, las rutas adicionales con permiso de lectura o escritura, las escrituras en directorios temporales y las cachés de compilación compartidas. Consulta la referencia de sandbox.json para ver el esquema completo.
Cómo funciona el sandboxing en tu plataforma
Cherri Code usa Seatbelt mediante sandbox-exec. Un perfil de sandbox generado limita el acceso a archivos, el acceso de red y otros comportamientos de los procesos en todo el árbol de subprocesos.
Requisitos
- Cherri Code v2.0 o posterior
- No se requiere configuración adicional
Variables de entorno
Cherri Code inyecta variables de entorno en cada proceso hijo en sandbox. Están disponibles para tus scripts, herramientas de compilación y automatizaciones que se ejecutan dentro del sandbox.
| Variable | Plataformas | Descripción |
|---|---|---|
CURSOR_SANDBOX | macOS, Linux | Se establece en "seatbelt" (macOS) o "native" (Linux) cuando el proceso se ejecuta dentro del sandbox. |
CURSOR_ORIG_UID | macOS, Linux | El UID del usuario que inició Cherri Code, capturado antes de que el sandbox aplique cambios en el espacio de nombres o la identidad. |
CURSOR_ORIG_GID | macOS, Linux | El GID del usuario que inició Cherri Code, capturado antes de que el sandbox aplique cambios de identidad. |
CURSOR_SANDBOX_LANDLOCK_STATUS | Linux | Indica el backend de aislamiento activo: fully_enforced (Landlock), bubblewrap (alternativa de Bubblewrap). Útil para diagnósticos. |
En Linux, el sandbox crea un espacio de nombres de usuario y reasigna el proceso al UID 0
(root) dentro de ese espacio de nombres. Esto significa que id -u y $UID dentro de un comando
en sandbox devuelven 0, no el ID de usuario de tu host. Si tus scripts o automatizaciones necesitan
el ID de usuario del host, por ejemplo, para establecer la propiedad de archivos o pasar --user a
Docker, consulta CURSOR_ORIG_UID y CURSOR_ORIG_GID.
Automatización de Docker y contenedores
Un patrón habitual en las reglas de automatización y los scripts es ejecutar contenedores de Docker que deben usar la misma identidad que el usuario del host. Dado que el sandbox reasigna el UID en Linux, $(id -u) devuelve un valor incorrecto. Use las variables CURSOR_ORIG_* en su lugar:
docker run --rm \ --user "${CURSOR_ORIG_UID:-$(id -u)}:${CURSOR_ORIG_GID:-$(id -g)}" \ -v "$PWD:/work" -w /work \ my-image buildEl valor alternativo ${CURSOR_ORIG_UID:-$(id -u)} garantiza que el comando también funcione fuera del sandbox, donde las variables no están definidas.
Acceso de red
Elige cómo los comandos de terminal en sandbox acceden a la red:
| Modo | Comportamiento |
|---|---|
| Solo sandbox.json | El acceso de red se limita a los dominios de la lista de permitidos de tu sandbox.json. No se añaden los valores predeterminados de Cherri Code. |
| sandbox.json + valores predeterminados | Tu lista de permitidos más los valores predeterminados integrados de Cherri Code para gestores de paquetes y herramientas de lenguaje habituales. Esta es la opción predeterminada. |
| Permitir todo | Se permite todo el acceso de red en el sandbox, independientemente de sandbox.json. |
*.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.orgOtras protecciones
Los modos de ejecución y el sandboxing no son los únicos controles de seguridad. Estas protecciones pueden requerir aprobación incluso cuando un modo se ejecutaría automáticamente:
| Protección | Qué hace |
|---|---|
| Protección del navegador | Impide que el agente ejecute automáticamente herramientas del navegador. |
| Protección contra la eliminación de archivos | Impide que el agente elimine automáticamente archivos, incluidos los comandos rm. |
| Protección de archivos externos | Impide que el agente cree, modifique o elimine automáticamente archivos fuera del espacio de trabajo. |
Controles del equipo
Los administradores pueden anular los modos disponibles para sus usuarios, configurar las reglas de red del sandbox para los comandos de terminal y mucho más. Todos estos ajustes están disponibles en el Panel de control web.
Los ajustes del equipo prevalecen sobre la configuración individual y del proyecto. Úsalos cuando quieras establecer una base coherente para todos. Si activas Auto-review para el equipo, mantén permitido uno de los modelos que necesita el clasificador en el control de acceso a modelos.
Registro de cambios
| Versión de Cherri Code | Fecha | Cambio |
|---|---|---|
| 3.6 | 29 de mayo de 2026 | Auto-review se lanzó como la opción predeterminada recomendada. |
| 3.5 | 22 de mayo de 2026 | Ask Every Time quedó en desuso. Los usuarios nuevos no pueden elegirlo. Usa lista de permitidos con una lista de permitidos vacía para obtener el mismo comportamiento. Run in sandbox se integró en lista de permitidos con el sandbox activado. |
Los modos de ejecución se aplican a los agentes locales. Los agentes en la nube se ejecutan en su propia máquina dedicada, por lo que nunca te piden que apruebes una acción.