Buenas prácticas
Todos los permisos, sin destrozar tu máquina
Las solicitudes de aprobación son lo que deja inútil a un agente cuando no estás, y desactivarlas en tu portátil es como la gente pierde una tarde. La solución no es la valentía. Es poner el agente en un sitio que no te importaría reconstruir.
Respuesta rápida
--dangerously-skip-permissions ejecuta todas las llamadas a herramientas sin preguntar. Anthropic dice que solo se use en contenedores o máquinas virtuales aislados, y Claude Code lo rechaza como root. Ejecútalo con un usuario que no sea root en un servidor o contenedor desechable sin secretos de producción. O usa el modo auto, en el que un clasificador aprueba las acciones seguras. La app móvil de Anthropic no puede pasar una sesión a bypass.
Claude Code pregunta antes de hacer cualquier cosa con consecuencias. En el escritorio no pasa nada: echas un vistazo, apruebas y sigues. Lejos del escritorio, bloquea el trabajo. El agente se detiene en el paso tres de una tarea de veinte minutos y espera un toque que llega cuarenta minutos después, cuando la gracia de delegarla era precisamente que no estuvieras mirando.
Así que la gente recurre a --dangerously-skip-permissions. Ese flag es peligroso en la máquina equivocada y razonable en la correcta, y la diferencia no está en lo cuidadoso que seas. Está en a qué puede llegar el agente cuando hace algo que no pretendías. Esta página explica qué hace realmente el flag, por qué no funciona como root, la configuración que lo hace defendible y los equivalentes en Codex, OpenCode, Grok Build y Antigravity.
Qué permite realmente bypass
Claude Code tiene seis modos de permisos. La página de modos de permisos de Anthropic los describe así. La tabla sigue el orden de la documentación: default es el nombre de configuración del modo Manual, no el modo con el que arranca una sesión.
| Modo | Se ejecuta sin preguntar | «Ideal para», según Anthropic |
|---|---|---|
default (Manual) | Solo lecturas | Trabajo delicado |
acceptEdits | Lecturas, ediciones de archivos, comandos habituales del sistema de archivos | Iterar sobre código que estás revisando |
plan | Lecturas, más comandos aprobados por el clasificador cuando el modo auto está disponible | Explorar antes de cambiar |
auto | Todo, con comprobaciones de seguridad en segundo plano | Tareas largas, menos solicitudes |
dontAsk | Lecturas y herramientas aprobadas de antemano; todo lo demás se deniega | CI blindada |
bypassPermissions | Todo | Solo contenedores y máquinas virtuales aislados |
Bypass ejecuta cada llamada a herramienta de inmediato, incluidas las escrituras en rutas protegidas como .git y la propia configuración de Claude. Algunas cosas se mantienen:
- Las reglas deny de tu configuración bloquean en todos los modos, bypass incluido. Las reglas allow no tienen efecto en él.
- Las reglas ask explícitas siguen preguntando.
rmyrmdirdirigidos a rutas críticas siguen preguntando: la raíz del sistema de archivos, los directorios de primer nivel, tu directorio personal, y el directorio de trabajo y sus padres.
Lo que bypass no te da es ninguna defensa frente a la inyección de prompts o un comando equivocado ejecutado con total seguridad. La documentación de Anthropic lo dice claramente: úsalo solo en entornos aislados donde Claude Code no pueda dañar tu máquina anfitriona.
Desde Claude Code v2.1.283, el modo auto es el modo inicial integrado de las sesiones interactivas en el terminal y en VS Code. Un segundo modelo revisa cada acción y bloquea las arriesgadas, como borrados masivos en almacenamiento en la nube, force pushes o lanzar otro bucle de agente con las aprobaciones y el sandbox desactivados. Elimina la mayoría de las solicitudes sin eliminar todas las comprobaciones. Necesita un modelo compatible, y una organización puede desactivarlo. Si el modo auto basta para tu tarea, puede que no necesites bypass en absoluto.
Dos flags que se parecen
--dangerously-skip-permissionsinicia la sesión en bypass. Equivale a--permission-mode bypassPermissions.--allow-dangerously-skip-permissionssolo añade bypass al ciclo de Shift+Tab. La sesión arranca en un modo normal y pasas a bypass cuando tú decides.
El segundo importa porque no puedes entrar en bypass desde una sesión que no se inició con él habilitado. Si es posible que lo quieras después, tienes que decidirlo al arrancar. La forma --allow- es la manera prudente de hacerlo: la sesión se comporta con normalidad hasta que cambias a propósito.
El primer arranque interactivo con bypass habilitado muestra un diálogo de advertencia. Aceptarlo escribe skipDangerousModePermissionPrompt: true en ~/.claude/settings.json; rechazarlo hace que Claude Code se cierre. Las ejecuciones no interactivas con -p se saltan el diálogo. Los administradores pueden bloquear el modo para todos con permissions.disableBypassPermissionsMode: "disable" en la configuración gestionada.
Por qué falla como root
En Linux y macOS, Claude Code se niega a arrancar en modo bypass como root o con sudo:
--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasonsLa comprobación se omite dentro de un sandbox que Claude Code reconoce, y el dev container de Anthropic lo ejecuta con un usuario que no es root por ese motivo. En un VPS normal en el que entras como root, crea primero un usuario normal. Nuestra guía de instalación en VPS tiene los tres comandos.
Aprendimos tres cosas prácticas ejecutando Claude Code bajo el daemon de Maude en muchos servidores distintos:
- Como root, la forma
--allow-también falló. En nuestras pruebas con Claude Code 2.1.x, el proceso se cerraba al lanzarse, en lugar de simplemente dejar bypass fuera del ciclo. Cualquier wrapper que añada el flag tiene que comprobar antes el ID de usuario, o morirán todas las sesiones de un servidor que funcione como root. - Las versiones antiguas rechazan el flag directamente. Una CLI que no conoce el flag se cierra del mismo modo. Comprueba que aparece en
claude --helpantes de pasarlo. - Prueba en una máquina limpia. Tu propio
~/.claude/settings.jsonprobablemente ya tieneskipDangerousModePermissionPromptdesde el día en que aceptaste la advertencia. En un servidor nuevo, ese diálogo aparece antes del prompt y una sesión desatendida se queda esperando en él. Prueba en un contenedor limpio, no en tu portátil.
El patrón del servidor desechable
Antes de relajar los permisos en cualquier sitio, hazte una pregunta: si este proceso ejecutara ahora mismo un comando destructivo cualquiera, ¿qué perdería?
En un portátil típico, la respuesta sincera es incómoda: tus claves SSH, las credenciales de la nube en ~/.aws y ~/.config, perfiles de navegador con sesiones abiertas, un .env con URL de producción y todos los demás repositorios que tengas clonados. En un VPS desechable con un solo proyecto, la respuesta es ese proyecto, que de todos modos está subido, más una hora de reconstrucción. Ese es un riesgo asumible. Hay tres sitios donde poner el agente:
Un contenedor en tu propia máquina
Es la opción más barata y cercana. Ejecuta un contenedor Linux con Docker u OrbStack, instala Claude Code dentro con un usuario que no sea root y monta solo el proyecto que quieres que toque. No montes tu directorio personal, no le pases credenciales de la máquina anfitriona y no uses --privileged ni montes el socket de Docker, porque ambas cosas le devuelven el control del anfitrión.
Un VPS dedicado
Es la opción por la que se decanta la mayoría: una máquina pequeña con uno o dos proyectos y nada más. Está siempre encendida, así que el trabajo sigue mientras tus propias máquinas están apagadas. Si alguna vez la comprometen, la destruyes y montas otra. Haz que reconstruirla sea aburrido, con un script de instalación corto en lugar de una máquina que llevas un año ajustando a mano. La guía de compra de VPS explica cómo dimensionarla.
Un sandbox efímero en la nube
Las sesiones en la nube de Anthropic ejecutan cada tarea en una máquina virtual aislada, con las credenciales de git fuera del sandbox y el acceso a la red limitado por defecto. Es un aislamiento fuerte sin nada que mantener. Pero bypass no está disponible ahí. Las sesiones en la nube ofrecen Accept edits, Plan y Auto, e ignoran el bypassPermissions que se configure en los ajustes de un repositorio.
Secretos que no deben estar en la máquina
- Credenciales de producción. Apúntalo a staging o a una copia local. El fallo del que te proteges no es la malicia; es un error cometido con total seguridad contra una cadena de conexión que casualmente estaba por ahí.
- Tu clave SSH personal. Dale al servidor su propia deploy key o un token de permisos acotados, limitado a los repositorios que necesita. Tampoco uses el reenvío del agente SSH hacia él: eso le presta tus claves a la máquina mientras estés conectado.
- Tokens de nube amplios. Nada de claves de AWS de administrador ni tokens de GitHub para toda la organización. Si una tarea necesita uno, acótalo y deja que caduque.
- Cualquier cosa que solo exista ahí. Haz push a menudo, para que perder el servidor no te cueste nada que no puedas recrear.
Hay una credencial que sí tiene que vivir en la máquina: el inicio de sesión del propio agente. Claude Code la guarda en ~/.claude/.credentials.json, así que cualquiera con una shell como ese usuario puede usar tu plan. Es un motivo más para darle al agente un usuario propio.
Equivalentes en Codex y otros agentes
Cada agente de código tiene su propia versión de este interruptor, y no todas significan lo mismo:
| Agente | Saltarse todas las solicitudes | Término medio más seguro |
|---|---|---|
| Claude Code | --dangerously-skip-permissions (rechazado como root) | Modo auto; acceptEdits; reglas deny |
| Codex | --dangerously-bypass-approvals-and-sandbox, alias --yolo: «Only use inside an externally hardened environment» | --sandbox workspace-write con aprobaciones bajo demanda (red desactivada por defecto). --full-auto es ahora un alias obsoleto de esto |
| OpenCode | opencode --auto (las reglas deny se siguen aplicando) | allow / ask / deny por herramienta en opencode.json. Ojo: la mayoría de las herramientas están en allow por defecto |
| Grok Build | grok --always-approve (las reglas deny y los hooks PreToolUse se siguen aplicando) | Modo auto (un clasificador aprueba las herramientas seguras); un sandbox aparte limita las llamadas aprobadas |
| Antigravity CLI | agy --dangerously-skip-permissions | Listas allow, ask y deny (deny tiene prioridad); el preajuste por defecto ejecuta los comandos de terminal en un sandbox sin red en macOS y Linux |
Fuentes: referencia de Codex CLI y aprobaciones y seguridad, permisos de OpenCode, permisos de Grok Build, permisos de Antigravity y el codelab de Antigravity CLI de Google, consultados en octubre de 2026. Codex y Antigravity usan sandbox por defecto, así que desactivar sus solicitudes y desactivar su sandbox son decisiones distintas. Desactivar el sandbox es la que requiere la máquina desechable.
¿Puedo activar bypass desde el móvil?
Desde la app de Claude, no. La documentación móvil de Anthropic dice que no puedes seleccionar Bypass permissions desde la app, ni para sesiones en la nube ni para Remote Control, y Remote Control desde la app tampoco ofrece Auto. Para un cliente de uso general, es un valor por defecto sensato.
Maude está pensado para el otro caso, un servidor tuyo que podrías reconstruir, así que ofrece el modo de acceso total de cada agente como «yolo», junto a los demás modos del agente. Para Claude, solo surte efecto cuando el daemon se ejecuta con un usuario que no es root y el Claude Code instalado admite el flag. Si no, la sesión se queda en un modo normal. Maude inicia la sesión en un modo normal y cambia a bypass después del arranque, nunca al lanzarla. En un servidor que solo tiene root, un botón de la app crea un usuario normal por ti. Puedes fijar un modo por defecto para cada agente o cambiarlo en cada sesión.
Los permisos totales son una decisión sobre dónde se ejecuta el agente, no un ajuste de riesgo. Pon Claude Code con un usuario que no sea root, en una máquina sin nada que valga la pena robar y nada que no puedas reconstruir, y podrás dejarlo trabajar desatendido sin preocuparte. Déjalo en la máquina que guarda tus claves y el trabajo de tus clientes, y ningún cuidado hará que el trato salga a cuenta.
Úsalo desde el móvil
Si ya has montado el servidor desechable, Claude Code en el móvil muestra cómo lo ejecuta Maude ahí. Aprobar los permisos de los agentes desde el móvil cubre el enfoque contrario: mantener las solicitudes activas y responderlas desde una notificación.
Preguntas frecuentes
¿Es seguro --dangerously-skip-permissions?
¿Por qué falla como root?
--allow-dangerously-skip-permissions como root también hacía que el proceso se cerrara al lanzarse.¿Cuál es el equivalente en Codex?
codex --dangerously-bypass-approvals-and-sandbox, también escrito --yolo, que desactiva tanto las aprobaciones como el sandbox. OpenAI dice que solo se use dentro de un entorno blindado externamente. El valor por defecto de baja fricción es --sandbox workspace-write con aprobaciones bajo demanda. El antiguo --full-auto está obsoleto y muestra una advertencia.¿Puedo activar bypass desde el móvil?
¿Qué diferencia hay entre los dos flags de saltar permisos?
--dangerously-skip-permissions inicia la sesión en modo bypass. --allow-dangerously-skip-permissions la inicia en un modo normal y solo añade bypass al ciclo de Shift+Tab, para que puedas cambiar a él más tarde. En una sesión iniciada sin ninguno de los dos no puedes pasar a bypass de ninguna manera.Qué ha cambiado
- — Reescrito: restricción de root, --allow-dangerously-skip-permissions frente a --dangerously-skip-permissions, el modo auto como término medio por defecto, lo que bypass sigue bloqueando, equivalentes en Codex/OpenCode/Grok Build/Antigravity, y lo que permiten la app móvil de Anthropic y Maude.
- — Primera publicación.
