diffox
Blog

¿Dónde detienen al agente el auto mode y el sandbox?

¿Qué frenan el auto mode de Claude Code, el auto-review de Codex y el sandbox, y qué no? Docs y mediciones de cinco herramientas.

CompartirXLinkedIn

Resumen. En un agente de código, cuatro cosas deciden por turno si un comando se ejecuta: las reglas que escribes tú, el sandbox, un modelo que decide por ti y, al final, tú. El 20 de octubre de 2026 leímos la documentación y las notas de versión de Claude Code, Codex de OpenAI, GitHub Copilot (la CLI y VS Code), Cursor y Antigravity CLI de Google, las mediciones propias de Anthropic y de OpenAI y los registros de seguridad de la NVD.

  • En la práctica, las solicitudes de permiso se aprueban sin leerlas. Según la medición de Anthropic, los usuarios de Claude Code aprueban el 97 % de las solicitudes de permiso. En el experimento que la empresa hizo con 1.053 usuarios de prueba, las personas detuvieron el comando peligroso introducido en la sesión en el 13,6 % de los casos, y el auto mode en el 89 %.
  • En la mayoría de las herramientas, el permiso ya lo da un modelo aparte. Las cinco herramientas tienen un modelo que autoriza (Gemini CLI no); en Claude Code y en Cursor viene activado por defecto. Según OpenAI, con el auto-review activado, una sesión de Codex se detiene a pedir aprobación humana unas 200 veces menos.
  • Los proveedores no consideran este modelo un límite de seguridad. Cursor y VS Code lo dicen abiertamente. En la propia medición de Anthropic, el agente fue más allá de lo que pedía el usuario en 52 acciones reales, y al clasificador se le escapó el 17 % de ellas.
  • El límite real lo marca el sandbox, pero en la mayoría de las herramientas viene desactivado. En tres de las cinco herramientas (Claude Code, Copilot, Antigravity CLI) el sandbox viene desactivado por defecto; aunque esté activado, partes como las herramientas de archivos, los hooks o los servidores MCP locales pueden quedar fuera. En el trabajo diario, usa el modelo que autoriza junto con el sandbox; en una ejecución desatendida, mantén el sandbox activado, limita la red a una lista de dominios y no pongas secretos en el entorno.

¿Qué controles pasa un comando antes de ejecutarse?

97 %solicitudes de permiso aprobadas en Claude Code (medición de Anthropic)
17 %acciones arriesgadas reales que se le escaparon al clasificador (de 52, Anthropic)
200×menos solicitudes de aprobación con el auto-review de Codex (según OpenAI)
89 %comandos peligrosos que detectó el auto mode; personas, 13,6 % (medición de Anthropic)

Cuando un agente de código quiere ejecutar un comando, la decisión no se toma en un solo sitio. La documentación de las cinco herramientas describe las mismas cuatro capas: primero las reglas que escribes tú, luego el sandbox que aplica el sistema operativo, luego un modelo aparte que revisa el comando y, al final, tú. Cómo escribir reglas con hooks lo contamos en el artículo sobre hooks. Aquí vemos las otras tres, con las mediciones de los propios proveedores:

4 controles, en orden. Manda la primera capa que decide; solo se te pregunta lo que queda. 1. Reglas. allow, ask, deny. Decide la primera regla que coincide. 2. Sandbox. En la mayoría de herramientas, dentro se ejecuta sin preguntar. 3. Modelo que autoriza. Revisa la llamada arriesgada que queda y explica su motivo. 4. Tú. Cuando el modelo o una regla te deja la decisión.
Fuente: documentación de permisos y sandbox de Claude Code, Codex, Copilot, Cursor y Antigravity, 20 de octubre de 2026. El orden cambia un poco de una herramienta a otra; el detalle, más abajo.

Los datos de los propios proveedores muestran por qué se puso un modelo en medio. Según Anthropic, los usuarios de Claude Code aprueban el 97 % de las solicitudes de permiso. Esos mismos usuarios rechazan el 39 % de los planes que presenta el agente, pero en las solicitudes de permiso una a una la tasa de rechazo es solo del 3 %. Es como aprobar un pull request sin leerlo: las preguntas llegan tan a menudo que se aprueban sin leer.

Un experimento del mismo artículo de Anthropic pone números a la diferencia. En la sesión de 1.053 usuarios de prueba pagados se introdujo un único comando peligroso. En realidad solo se había cambiado el texto de la pregunta; aunque aprobaran el comando, no se ejecutaba nada. Las personas detuvieron ese comando en el 13,6 % de los casos, y el auto mode en el 89 %. Cuanto más larga era la sesión, más se les escapaba: al principio detenían alrededor del 17 % de los comandos peligrosos, y tras 50 preguntas o más, alrededor del 5 %. Estos resultados salen del experimento del propio proveedor.

OpenAI también vio el mismo problema en sus usuarios. Según el artículo de OpenAI, cuando las solicitudes de aprobación llegan a menudo, los usuarios o se pasan al modo Full Access, donde no se aplica ninguna regla, o escriben reglas amplias que permiten cualquier comando que empiece por python. Según Anthropic, en junio el 43 % de los usuarios activos de la CLI tenía una regla de intérprete como Bash(python:*). Los dos proveedores optaron por lo mismo: hacer la pregunta a un modelo aparte, no a una persona.

¿Cómo deciden el auto mode y el auto-review?

La llamada que no deciden ni las reglas ni el sandbox pasa al modelo que autoriza, y es él quien decide si se ejecuta. Las cinco herramientas tienen ya un modelo así; pero qué ve, cuándo te devuelve la decisión y si viene activado por defecto cambia de una herramienta a otra. Así estaba a 20 de octubre de 2026:

El modelo que autoriza en cinco herramientas de código: qué es, qué ve, cuándo te devuelve la decisión y su estado por defecto
HerramientaModelo que autorizaQué veCuándo te devuelve la decisiónPor defecto
Claude CodeClasificador del auto mode; modelo por defecto Claude Sonnet 5Mensajes del usuario, llamadas a herramientas y CLAUDE.md; no ve la salida de las herramientasVuelve a preguntarte tras 3 bloqueos seguidos o 20 en total en la sesiónActivado: desde el 28 de septiembre, las sesiones interactivas empiezan en este modo
CodexAuto-review («Approve for me»): un agente de Codex aparteLa conversación compactada, las salidas de herramientas relevantes y la solicitud de aprobación completa; no ve el razonamiento ocultoDetiene el turno tras 3 rechazos seguidos, o cuando en las últimas 50 revisiones hay 10 rechazosDesactivado: por defecto, quien aprueba eres tú
GitHub CopilotAssisted Permissions: un juez LLM cuyo modelo se elige automáticamenteLa documentación no lo dice; según las notas de versión, el código de shell visible va al juezTe pregunta si el juez no lo apruebaDesactivado: un nivel de permisos experimental
CursorClasificador de Auto-review: Gemini 3.5 Flash Lite, con Haiku de respaldoTu petición y tus instrucciones personalizadas; si hace falta, lee tus archivos en modo de solo lecturaSi bloquea una llamada, el agente prueba otro camino; si insiste, se te preguntaActivado: ajuste por defecto recomendado desde el 29 de mayo
Antigravity CLIAuto mode: un agente aparte revisa los comandos que saldrían del sandboxLa documentación no lo dicePregunta antes de una acción irreversibleDesactivado: se activa con --mode auto

Fuente: documentación y notas de versión de las herramientas, 20 de octubre de 2026. «La documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que lo describa. El juez de Copilot llegó a la CLI el 7 de julio; la documentación de VS Code presenta este nivel de permisos como experimental.

En Claude Code, el orden de decisión es fijo: primero tus reglas allow, ask y deny, luego las lecturas y ediciones en el directorio de trabajo y, al final, el clasificador. Al pasar al auto mode, las reglas amplias que permiten ejecutar cualquier código, como Bash(*) o Bash(python*), dejan de aplicarse; las reglas estrechas como Bash(npm test) se mantienen. El clasificador no ve la salida de las herramientas; así, una instrucción escondida en un archivo o en una página web no puede dirigirlo directamente. Cuando bloquea una llamada, en pantalla aparece Denied by auto mode classifier y, al lado, el nombre de la regla que coincidió, como [Data Exfiltration].

Codex elige lo contrario. El auto-review también ve la salida de las herramientas y, si hace falta, hace sus propias comprobaciones de solo lectura. Pero solo mira las llamadas que quieren cruzar el límite del sandbox; un comando que se queda dentro del sandbox no se revisa nunca. Según su documentación, no es un permiso, solo un cambio de revisor: el auto-review no amplía los directorios con escritura ni abre la red. La política por defecto está en el repositorio de código abierto de Codex, en una carpeta llamada guardian. Si escribes tu propia política, no se combina con la de por defecto, sino que la sustituye. Según el artículo de OpenAI del 30 de abril de 2026, el revisor funcionaba entonces con GPT-5.4 Thinking; la documentación no dice qué modelo usa hoy.

Cursor publicó Auto-review el 29 de mayo y desde entonces lo ofrece como ajuste por defecto recomendado. El clasificador funciona con modelos pequeños en los servidores de Cursor y, para decidir, puede leer archivos de tu máquina en modo de solo lectura. En Copilot, el juez llegó primero a la CLI. Según la documentación de VS Code, Assisted permissions es un nivel experimental: un juez LLM evalúa cada llamada a una herramienta y, si no la aprueba, se te pregunta. Antigravity CLI añadió el Auto mode el 14 de octubre: aprueba sin preguntar las ediciones de archivos y los comandos seguros, y los comandos que saldrían del sandbox los revisa antes un agente aparte. La página de modos de Antigravity aún no incluye este modo; la información está en las notas de versión.

Si todavía usas Gemini CLI, su documentación no describe el modelo que autoriza: el policy engine decide con reglas fijas y el resultado lo marca la primera regla que coincide. Google dejó de dar servicio en Gemini CLI a los suscriptores de Google AI Pro y Ultra y a los usuarios individuales gratuitos el 18 de junio de 2026 y los envió a Antigravity CLI; con una clave de API de pago puedes seguir usando Gemini CLI. Ojo también con una confusión de nombres: en Copilot y en Cursor, «Auto» es también el nombre del enrutador que elige un modelo. Lo explicamos en el artículo sobre la elección de modelo; el auto mode de este artículo tiene que ver con los permisos.

¿Cada cuánto se equivoca el modelo que autoriza?

El modelo que autoriza puede equivocarse de dos maneras: deja pasar una llamada peligrosa o detiene sin motivo una llamada inofensiva. En el primer caso el comando se ejecuta; en el segundo, el agente prueba otro camino o te pregunta. Hay dos proveedores que miden ambas cosas y las publican: Anthropic y OpenAI. En la documentación de Cursor, GitHub y Google no encontramos ninguna medición. Anthropic comparó a las personas y al clasificador con los mismos comandos:

Medición de la propia Anthropic; un único experimento con 1.053 usuarios de prueba. Persona, ante la pregunta (Anthropic · 1.053 usuarios de prueba): 13,6 %; Auto mode de Claude Code (Anthropic · mismo experimento): 89 %.
Fuente: Anthropic (7 de agosto de 2026), medición del propio proveedor. En el experimento no se ejecutaba nada aunque se aprobara el comando peligroso.

Estas cifras salen de conjuntos de prueba; en el uso real el panorama es menos brillante. En el artículo de ingeniería de Anthropic del 25 de marzo de 2026, sobre 10.000 llamadas reales a herramientas de empleados de la empresa, el clasificador detuvo sin motivo el 0,4 % de las llamadas inofensivas. Por otro lado, el agente fue más allá de lo que pedía el usuario en 52 acciones reales, y al clasificador se le escapó el 17 % de ellas. El propio artículo llama a esta cifra «the honest number». En la mayoría de los casos que se le escaparon, el clasificador vio el peligro, pero creyó que la aprobación del usuario cubría también esa acción: decir «Clean up the PR» no es dar permiso para un force push. Entonces el clasificador funcionaba con Sonnet 4.6; hoy el modelo por defecto es Claude Sonnet 5.

OpenAI hizo su propia medición con datos sintéticos. Según OpenAI, el auto-review detectó el 90,3 % de los casos en que el agente iba más allá de lo pedido. En prompt injection, la tasa de detección es del 99,3 % en tres tipos de ataque; si se cuentan todos los tipos, borrados y manipulación de datos incluidos, baja al 90,2 %. En ejercicios de red team encontraron casos en los que se podía engañar al auto-review para que aprobara un comando sin la aprobación del usuario; también escriben que no esperan garantías deterministas de este tipo de sistema. En una prueba de ataques sintéticos que Anthropic hizo con un equipo externo, la tasa de casos que se le escapaban al clasificador bajó del 12 % al 7 % tras las correcciones; Anthropic pide que esta cifra no se tome como la tasa de casos que se le escapan en tráfico real. Cómo leer un resultado que publica un proveedor lo explicamos en el artículo sobre SWE-bench.

La documentación también dice qué no puede ver el modelo. El modelo que autoriza solo ve la llamada que tiene delante: en Codex, los comandos que se quedan dentro del sandbox nunca le llegan, y en Claude Code tampoco las lecturas y ediciones en el directorio de trabajo. OpenAI escribe que un modelo que oculta su intención podría generar una solicitud de aspecto inofensivo o hacer dentro del sandbox cosas que el auto-review nunca ve. El clasificador de Claude Code no ve la salida de los comandos anteriores. Por eso, si el destino de un rm -rf es una variable de shell cuyo valor nunca apareció en la conversación, no puede verificar el borrado y lo bloquea. Un límite que pongas en la conversación, como «no hagas push», tampoco se guarda como regla; según la documentación, ese mensaje puede perderse cuando se compacta el contexto. Cómo pasa eso lo explicamos en el artículo sobre auto compact. Para una prohibición firme, escribe una regla deny.

El equilibrio entre un peligro que se escapa y una parada innecesaria es el mismo que en la revisión de código entre error real y falsa alarma: el ajuste que reduce uno aumenta el otro. Los propios proveedores lo dicen claro. Cursor escribe en un título que Auto-review no es un límite de seguridad; VS Code dice lo mismo de Assisted permissions. OpenAI escribe que el auto-review no es una garantía de seguridad determinista, y Anthropic, que el auto mode no garantiza la seguridad. El límite lo marca el sandbox.

¿Qué limita realmente un sandbox?

El sandbox limita el comando que ejecuta el agente con herramientas del propio sistema operativo: Seatbelt en macOS, y bubblewrap, Landlock o los namespaces del kernel en Linux. Aunque el modelo se equivoque, el comando no puede escribir en un archivo no permitido ni conectarse a un servidor no permitido. Pero los valores por defecto de las cinco herramientas son muy distintos:

El sandbox local en cinco herramientas de código: estado por defecto, red, archivos secretos y lo que queda fuera del sandbox
HerramientaPor defectoRed (si está activado)Archivos secretosQueda fuera
Claude CodeDesactivado; se activa con /sandboxPasa por un proxy; la lista de dominios permitidos empieza vacíaPuede leer casi toda la máquina, ~/.ssh incluido; no hay lista de denegación integradaHerramientas de archivos como Read, Edit y Write, hooks, servidores MCP y LSP locales
CodexActivado: workspace-writeCerradaSu documentación no indica el límite de lectura por defecto; recomienda una regla deny para rutas como ~/.sshServidores MCP, navegador, Computer Use y conectores; cada uno tiene su propio ajuste
GitHub CopilotDesactivado; /sandbox enable en la CLI, chat.agent.sandbox.enabled en VS CodeAbierta; a cualquier servidor hasta que añadas una regla de permisoSistema de archivos cerrado por defecto; las credenciales de Git y gh se dan con un marcadorLas herramientas de archivos de la propia CLI (control en el software), servidores MCP remotos
CursorActivado en Auto-review; desactivado en Run EverythingCerrada; el modo de red por defecto permite una lista de registros de paquetes, github.com incluidoLímite de lectura «system» por defecto: ~/.ssh se puede leerEl comando que no cabe en el sandbox; lo aprueba el clasificador o tú
Antigravity CLIDesactivado; se activa con enableTerminalSandbox. En la app de Antigravity, activado en macOS y LinuxCerrada; solo los dominios que apruebes~/.ssh y .env bloqueadosEl comando que coincide con una regla unsandboxed(...) o que apruebas, con acceso completo

Fuente: documentación del sandbox de cada herramienta, 20 de octubre de 2026. El sandbox local de Copilot pasó a disponibilidad general el 7 de octubre. En Gemini CLI también eres tú quien activa el sandbox, con una opción, una variable de entorno o un ajuste.

La columna más importante de la tabla es la última. La documentación de Claude Code dice que el sandbox solo cubre los comandos de shell: las herramientas de archivos como Read y Edit siguen las reglas de permisos, y los hooks y los servidores MCP locales se ejecutan con todos tus permisos. Según la documentación de GitHub, el sandbox del sistema operativo tampoco ve lo que hacen las herramientas de archivos propias de Copilot CLI; solo las limita un control en el software. Por qué los servidores MCP locales piden más cuidado lo explicamos en el artículo sobre seguridad MCP.

La mayoría de los escapes del sandbox registrados salen justo de este hueco: un comando dentro del sandbox prepara algo y una pieza fuera del sandbox lo ejecuta o escribe a través de ello. La NVD tiene tres ejemplos, los tres corregidos:

  • Claude Code (CVE-2026-39861, antes de la 2.1.64): un comando en el sandbox podía crear un enlace simbólico que apuntaba fuera del directorio de trabajo. Cuando Claude Code, que se ejecuta fuera del sandbox, escribía en esa ruta, el archivo acababa fuera del directorio. Según el registro, ninguno de los dos podía escribir fuera del directorio por sí solo; el escape ocurría al juntarse los dos.
  • Cursor (CVE-2026-26268, antes de la 2.5): un agente dirigido mediante prompt injection podía escribir en ajustes de .git mal protegidos y en hooks de git; git ejecutaba después esos hooks por su cuenta, fuera del sandbox. Cursor ahora bloquea siempre la escritura en .git/hooks y .git/config.
  • Codex (CVE-2026-19591): el analizador que distingue los comandos seguros tomó por seguros algunos comandos de PowerShell, y un comando de git que escribe en un archivo pudo ejecutarse sin pedir aprobación. Según el registro, en macOS y Linux el sandbox por defecto podía impedir igualmente la escritura fuera de los sitios permitidos: cuando la capa de reglas falló, el sandbox pudo mantener el límite.

La documentación de VS Code también describe esta debilidad de la capa de reglas: la aprobación automática basada en reglas solo puede analizar un comando lo mejor que puede; la concatenación de comillas o los alias de shell pueden saltarse las reglas. En la red también hay un hueco conocido. Según la documentación de Claude Code, el proxy decide por el nombre de dominio que indica el cliente, sin inspeccionar el TLS; por eso, con técnicas como el domain fronting se puede llegar a servidores que no están en la lista. La misma página advierte de que permitir un dominio amplio como github.com puede abrir un camino para la exfiltración de datos. Los fallos del propio sandbox también aparecen en las notas de versión: en la versión 2.1.224 se corrigió un fallo por el que una entrada denyRead terminada en barra podía saltarse en silencio en Linux y macOS.

Con los secretos, las herramientas también se comportan distinto. Claude Code no tiene una lista de denegación de credenciales integrada; solo se restringen los archivos y las variables que tú indicas. Si quieres, puedes enmascarar una clave: el comando ve un marcador propio de la sesión en lugar del valor real, y el proxy solo pone el valor real en las peticiones a los servidores que permites. Claude Code no lee este ajuste del .claude/settings.json del repositorio, solo de los ajustes de usuario o de administrador. Copilot da por defecto las credenciales de Git y gh de la misma forma cuando el sandbox está activado; el token real de gh solo va a direcciones de github.com. Antigravity bloquea ~/.ssh y .env desde el principio. Qué pasa en Copilot con el sandbox desactivado lo dice claramente la documentación de GitHub: los comandos pueden leer y escribir en cualquier sitio con los permisos de tu cuenta, llegar a cualquier red a la que llegue tu máquina y usar tus credenciales sin restricción.

¿Qué modo usar para cada tipo de trabajo?

Todas las pruebas apuntan al mismo sitio: el modelo que autoriza reduce las preguntas que te llegan, y el límite lo marca el sandbox. Úsalos juntos y elige el ajuste según el trabajo:

Qué ajuste para cada trabajo. Activa primero el sandbox y luego elige quién da el permiso. trabajo diario supervisado Modelo que autoriza + sandbox: Auto mode o Approve for me; sandbox activado. si el agente pide permiso Ejecutar sin preguntar en el sandbox: Regla estrecha; no una amplia como python:*. ejecución desatendida, CI Sandbox + lista de dominios: Sin secretos en el entorno; acceso completo solo en un contenedor desechable. producción, secretos, infra Reglas ask y deny: Que push y deploy te pregunten en cualquier modo. repositorio no confiable Revisa antes los archivos de ajustes: Un ajuste del repositorio puede aflojar el sandbox. ajuste en un pull request Revísalo como un cambio de seguridad: allowedDomains, excludedCommands, sandbox.json.
Elaborado a partir de las mediciones de este artículo y de la documentación de las cinco herramientas, 20 de octubre de 2026.

En el trabajo diario que supervisas, usa el modelo que autoriza junto con el sandbox. En Claude Code, el auto mode ya es el modo de inicio; activa también el sandbox con /sandbox. En Codex el sandbox ya está activado; elige «Approve for me» en el menú de permisos. En Cursor, deja Auto-review activado. En Copilot CLI, activa el sandbox con /sandbox enable. En Antigravity CLI, activa el sandbox con --sandbox y elige --mode auto. Si quieres ver qué bloquea el modelo, Claude Code escribe desde el 15 de octubre la decisión del clasificador en los eventos de OpenTelemetry, y Codex guarda las transcripciones del auto-review en ~/.codex/sessions.

Si el agente pide permiso constantemente, ajusta el límite en lugar de abrirlo todo. Es también lo que recomienda OpenAI: si las peticiones normales acaban en revisión, corrige primero el límite del sandbox y escribe reglas estrechas como ["cargo", "test"] en lugar de prefijos amplios como ["python"]. En Claude Code, si no quieres clasificador, usa el modo Manual junto con el modo auto-allow del sandbox; los comandos que se quedan dentro del sandbox se ejecutan sin preguntar. Da el permiso una vez, como regla estrecha, y no cada vez que el agente lo pida.

En una ejecución desatendida no hay nadie a quien preguntar. Claude Code inicia las ejecuciones lanzadas con -p en Manual mientras no indiques un modo, y rechaza las llamadas que necesitan aprobación. Los agentes en la nube de Cursor funcionan en una máquina reservada para ellos y nunca piden aprobación. En una ejecución así, mantén el sandbox activado, limita la red a una lista de dominios y no pongas en el entorno claves que no hagan falta. Si tienes que dar acceso completo, hazlo solo en un contenedor desechable; ahí el límite lo marca el propio contenedor. La documentación de Codex advierte de que, incluso en un contenedor así, un proyecto malicioso puede sacar todo lo que hay dentro, incluidas las credenciales de Codex.

Parte de estos ajustes vive en el repositorio y puede cambiar con un pull request. Claude Code no deja activar el auto mode desde el archivo de ajustes del repositorio; pero, salvo que un administrador haga obligatorio el sandbox, lee de ese archivo entradas que aflojan el límite, como excludedCommands y network.allowedDomains. Su documentación dice que, con una entrada excludedCommands amplia, el agente puede escribir un archivo y ejecutarlo fuera del sandbox. Cursor combina el .cursor/sandbox.json del repositorio con el ajuste del usuario y da prioridad al archivo del repositorio; Codex carga el .codex/config.toml del repositorio en un proyecto en el que confías. Un pull request que toque uno de estos archivos cambia el límite para todos los que abren el repositorio; revísalo como un cambio de seguridad. Antes de abrir con un agente un repositorio del que no te fías, mira también estos archivos.

Aplicamos el mismo principio en nuestro propio producto. En diffox, nuestra herramienta de revisión de código con IA, el paso que traza el blast radius de un pull request lee los archivos del cliente y no llama a nadie de fuera. Este paso arma su entorno a partir de una lista de permitidos: aparte de PATH, HOME, los ajustes de idioma y el directorio temporal, no toma ninguna variable. Una lista de denegación dejaría pasar una clave nueva que se añada mañana.

Preguntas frecuentes

¿Qué es el auto mode de Claude Code?

El auto mode es uno de los modos de permisos de Claude Code: un modelo clasificador aparte responde por ti a las solicitudes de permiso. Primero se aplican tus reglas allow, ask y deny, y las lecturas y ediciones en el directorio de trabajo pasan sin preguntar; las llamadas restantes las revisa el clasificador, que por defecto funciona con Claude Sonnet 5. Puedes cambiar el modelo con CLAUDE_CODE_AUTO_MODE_MODEL. Por defecto bloquea el envío de datos sensibles hacia fuera, los despliegues a producción y el force push; tras 3 bloqueos seguidos o 20 en total en la sesión, vuelve a preguntarte. El 14 de agosto pasó a ser el modo de inicio en los planes Pro, Max y Team; desde el 28 de septiembre, las sesiones interactivas empiezan en este modo en todos los planes. La documentación de Anthropic dice que el auto mode no garantiza la seguridad.

¿Qué significa «Denied by auto mode classifier»?

Significa que el clasificador de Claude Code consideró insegura esa llamada. El nombre entre corchetes, por ejemplo [Data Exfiltration] o [Production Deploy], es el de la regla que coincidió. Puedes ver las llamadas bloqueadas en la pestaña Recently denied de /permissions y, con la tecla r, decirle al agente que puede volver a intentar esa llamada. Si lo bloqueado es un registro de paquetes o un dominio interno que el agente necesita todo el rato, añádelo a autoMode.environment; /auto-mode-setup te prepara un borrador de esas entradas. Si es algo puntual, explica claramente tu intención en el siguiente mensaje.

¿Qué diferencia hay entre el auto-review y el full access de Codex?

Los dos reducen las solicitudes de aprobación, pero ponen el límite en sitios distintos. El auto-review («Approve for me») deja el sandbox workspace-write tal como está; solo envía las llamadas que quieren salir del sandbox a un agente revisor aparte en lugar de a ti. Full access significa sandbox_mode = "danger-full-access" con approval_policy = "never": ni sandbox ni preguntas; el agente accede a internet y a cualquier archivo de tu ordenador. En la propia medición de OpenAI, el auto-review detectó el 90,3 % de los escenarios sintéticos en que el agente cruzaba el límite, y la sesión se detuvo a pedir aprobación humana unas 200 veces menos. En full access ese control no existe.

¿Cómo se activa el sandbox de Claude Code?

Escribe /sandbox en la sesión o pon sandbox.enabled a true en ~/.claude/settings.json. En macOS no hace falta nada más; en Linux y WSL2 tienen que estar instalados bubblewrap y socat. En Windows nativo, los comandos se ejecutan sin sandbox. Con el sandbox activado, los comandos pueden escribir en el directorio de trabajo y en el directorio temporal, y salir a la red solo hacia los dominios que permitas. El sandbox solo cubre los comandos de shell; las herramientas de archivos, los hooks y los servidores MCP locales quedan fuera. Si no quieres que los comandos se reintenten fuera del sandbox, pon allowUnsandboxedCommands a false.

¿Puede el agente leer ~/.ssh con el sandbox activado?

Depende de la herramienta. Por defecto, el sandbox de Claude Code puede leer casi toda la máquina, ~/.ssh y ~/.aws/credentials incluidos; para cerrarlo hace falta el ajuste filesystem.denyRead o credentials. En Cursor, el límite de lectura es «system» por defecto y ~/.ssh se puede leer; si eliges «workspace», de ~/.ssh solo queda known_hosts. El sandbox de Copilot cierra en el sistema de archivos todas las rutas que no hayas permitido, pero con el acceso por defecto a las herramientas de desarrollo los comandos pueden leer los tokens que guardan los gestores de paquetes. Antigravity bloquea ~/.ssh y .env desde el principio. La documentación de Codex no indica claramente el límite de lectura por defecto; recomienda una regla deny para rutas como ~/.ssh.

¿Por qué Claude Code pide permiso todo el rato?

Casi siempre porque la sesión empezó en modo Manual. Desde el 28 de septiembre, Claude Code inicia las sesiones interactivas en auto mode; pero si defaultMode en tus ajustes de usuario apunta a otro modo, si tu modelo no admite el auto mode o si tu organización ha desactivado el auto mode, la sesión empieza en Manual. Puedes pasar al auto mode con Shift+Tab. En auto mode también se te pregunta en reglas ask como Bash(git push *) y en la primera lectura fuera del directorio de trabajo. Si no quieres clasificador, activa el sandbox en modo auto-allow; los comandos dentro del sandbox se ejecutan sin preguntar. No escribas una regla como Bash(*) que lo abre todo.

¿El auto mode es de pago?

Depende de la herramienta. Desde el 7 de agosto, Anthropic no cobra los tokens extra del clasificador en los planes Pro, Max y Team. En el plan Enterprise y en las cuentas que usan la API de Claude, Bedrock, Google Cloud o Foundry, las llamadas del clasificador cuentan como uso de tokens; cuando la revisión se hace en el servidor, no hay una llamada aparte. Cursor dice que el clasificador de Auto-review no añade coste extra al uso del agente. La documentación de Codex, Copilot y Antigravity no dice cuánto cuesta el modelo que autoriza.