Anthropic, en un acto raro de honestidad corporativa, llamó a uno de sus flags de Claude Code de la forma más literal posible: --dangerously-skip-permissions. Es decir: «sí, esto es peligroso, sí, salta los permisos, y no te quejes después». Si alguna vez tuvieras dudas sobre lo que hace, su nombre te ahorra el viaje a la documentación.

Y aun así, hay desarrolladores ejecutándolo a diario, en equipos de producto, en máquinas con acceso a producción, sin pestañear. Este artículo va sobre qué es exactamente claude –dangerously-skip-permissions, qué puede romper, qué alternativas existen y cuándo —si es que alguna vez— tiene sentido usarlo. Lo escribimos en Pango Studio porque trabajamos con Claude Code todos los días en proyectos Shopify y de IA aplicada al ecommerce, y los riesgos los hemos visto de primera mano.

Qué es claude –dangerously-skip-permissions

Claude Code es la CLI oficial de Anthropic para programar con Claude desde el terminal. Por defecto, cada vez que el agente quiere ejecutar una acción potencialmente disruptiva —correr un comando bash, escribir en un archivo, llamar a una API externa— te pregunta antes con una ventana de aprobación. Es un sistema de permisos por tool: «¿Permito a Claude correr git push?», sí o no.

El flag --dangerously-skip-permissions apaga ese sistema entero. Cuando ejecutas:

claude --dangerously-skip-permissions

le estás diciendo a Claude que tiene autonomía total. Bash, Edit, Write, Read, llamadas a MCPs, todo lo que haya en su caja de herramientas se ejecuta sin parar a preguntar. Tú abandonas la cabina. El piloto automático coge el mando. Si Claude decide que para resolver tu issue lo mejor es hacer git reset --hard origin/main, lo hace. Si decide que el archivo de configuración sobra, lo borra. Si decide que esa migración no se merece el rollback, no lo crea.

La comunidad lo apoda «modo YOLO» con una mezcla de cariño y miedo. En Reddit y X verás capturas de devs presumiendo de proyectos enteros completados con el flag activo. También verás capturas, días después, de los mismos devs explicando por qué su rama main acabó vacía.

Por qué existe el flag (y por qué Anthropic le puso ese nombre)

Hay una razón legítima: hay contextos donde la fricción de aprobar cada acción es contraproducente. Pipelines automatizados, contenedores efímeros, scripts de batch que procesan miles de archivos, demos en directo donde una pregunta cada 30 segundos rompe el flow. Para esos casos, Claude Code permite saltar el sistema de permisos.

El nombre del flag es la primera línea de defensa de Anthropic. No te lo van a poner fácil. No es --auto, ni --yes, ni --unattended. Es --dangerously-skip-permissions. Cada vez que lo escribes, lo lees. Cada vez que lo lees, asumes responsabilidad. Es la primera regla del UX defensivo: haz que lo peligroso sea visible.

Aun así, una vez te acostumbras, dejas de leerlo. Como cuando llevas años conduciendo y ya no piensas en el cinturón. Y ese es exactamente el problema.

Riesgos reales: qué puede romper Claude sin permisos

1. Comandos destructivos sin revisión

El más obvio. Claude puede ejecutar:

• rm -rf node_modules (esto es benigno).
• rm -rf ~/Documents (esto no).
• git push --force origin main sin avisar.
• git branch -D feature-rama-importante porque «ya no se usa».
• DROP TABLE customers; en una base de datos abierta porque malinterpretó el contexto.

El 99 % de las veces Claude hace lo correcto. El 1 % restante, sin permisos delante, no tiene a quién consultar. Y un 1 % aplicado a 50 acciones por sesión te garantiza un incidente al mes.

2. Modificación de archivos sensibles

Claude puede leer y escribir cualquier archivo del workspace. Si tu directorio incluye .env, credentials.json, claves SSH o tokens de API, en modo dangerously nada le impide leerlos, citarlos en sus respuestas, o por error pegarlos en un commit. Si trabajas con archivos sensibles, este flag es Russian roulette.

3. Deploys o publicaciones sin doble check

En proyectos donde Claude tiene acceso a herramientas de despliegue (Shopify CLI, Vercel, AWS, Heroku, MCP de WordPress…) puede hacer shopify theme push --live en producción si confunde la rama. Puede publicar un post como publish en vez de draft. Puede enviar un email transaccional a 50.000 clientes mientras testea una integración Klaviyo.

4. Cascada de cambios con sub-agents

Si combinas --dangerously-skip-permissions con sub-agents (la feature donde Claude lanza agentes paralelos), la cascada potencial se multiplica. Un agente principal sin permisos delegando en cinco sub-agents sin permisos es un cluster que puede tocar 200 archivos antes de que tú te enteres.

5. Costes inesperados

El flag no apaga solo la confirmación de archivos. Apaga también la confirmación de acciones que cuestan dinero. Una llamada a la API de OpenAI con un prompt de un millón de tokens, una subida masiva a fal.ai, un aws s3 sync que duplica buckets. Todo se ejecuta. Tu tarjeta lo paga. Anthropic no te cobra por el flag, pero sí los servicios que Claude tocó por el camino.

6. Logs y auditoría que se pierden

Algunas empresas reguladas (banca, salud, sectores con ENS, ISO 27001) necesitan que cada cambio sobre archivos críticos quede registrado con autorización humana explícita. --dangerously-skip-permissions rompe ese requisito de un plumazo. Si tu compliance officer te ve usándolo en un proyecto auditado, prepárate para una conversación incómoda.

Alternativas seguras al flag

Opción 1: lista blanca de tools (--allowedTools)

En vez de saltar todo el sistema de permisos, dile a Claude exactamente qué herramientas puede usar sin pedir confirmación. Por ejemplo:

claude --allowedTools "Read,Edit,Glob,Grep"

Con eso Claude puede leer y editar archivos pero te pregunta antes de ejecutar bash, escribir archivos nuevos o llamar a MCPs. Es el equilibrio razonable para sesiones de refactor o exploración de código.

Opción 2: --permission-mode

Claude Code tiene cuatro modos de permisos:

• default: pregunta cuando aplica. El sano por defecto.
• acceptEdits: acepta automáticamente solo las ediciones de archivos. Bash, MCPs y red siguen requiriendo permiso.
• bypassPermissions: equivalente a --dangerously-skip-permissions. Mismo significado, otro nombre.
• plan: Claude no toca archivos ni ejecuta comandos. Solo planea. Útil para auditorías y para que un humano apruebe el plan antes de ejecutar.

Para el 80 % de las sesiones, acceptEdits es el sweet spot.

Opción 3: settings.json con reglas finas

Puedes definir reglas a nivel de proyecto en .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm test*)",
      "Bash(git status)",
      "Bash(git diff*)",
      "Edit",
      "Read",
      "Grep"
    ],
    "deny": [
      "Bash(rm*)",
      "Bash(git push*)",
      "Bash(npm publish*)"
    ]
  }
}

Esto le dice a Claude: «puedes correr npm test, git status y git diff sin preguntar, pero rm, git push y npm publish los tienes prohibidos pase lo que pase». Es la forma más profesional de operar — y la que usamos por defecto en proyectos cliente en Pango.

Opción 4: contenedor o VM efímera

Si quieres correr --dangerously-skip-permissions sin riesgo real, hazlo en un sandbox. Un contenedor Docker que se borra al cerrar la sesión, un dev container, una VM con snapshot, un GitHub Codespace… cualquier entorno donde lo peor que pueda pasar es perder el estado del propio sandbox. El flag deja de ser peligroso si el entorno también es desechable.

Opción 5: git worktree dedicado

Si quieres autonomía sin contenedor, crea un worktree de Git aparte solo para el experimento. Si Claude la lía, descartas el worktree y vuelves a tu rama principal sin tocar nada. Truco simple pero efectivo:

git worktree add ../mi-experimento feature/yolo
cd ../mi-experimento
claude --dangerously-skip-permissions

Cuándo SÍ tiene sentido usarlo

No vamos a fingir que el flag es maligno. Hay casos legítimos:

• Pipelines de CI/CD donde un agente procesa una tarea cerrada y predefinida (generar release notes, traducir 200 ficheros, etiquetar issues). En ese contexto la fricción humana no aporta.
• Demos en directo donde la audiencia espera ver fluidez, no diálogos modales cada 20 segundos.
• Sandboxes desechables tipo contenedores efímeros donde el blast radius es nulo.
• Scripts de procesamiento batch sobre datos de prueba que se pueden regenerar.
• Workflows agentic largos donde la velocidad pesa más que la seguridad y el operador supervisa el log en tiempo real.

La regla mental que usamos en Pango: si tu pregunta es «¿qué pierdo si Claude la lía?», y la respuesta no es «nada importante», no uses el flag. Esa pregunta sirve de filtro fiable.

Cómo lo usamos en Pango Studio

Trabajamos con Claude Code todos los días en proyectos Shopify, integraciones, MCPs propios y posts SEO. Nuestro stack de permisos es escalonado:

• Proyectos cliente: permission-mode: default + settings.json con allow/deny específicos. Ningún despliegue automático sin aprobación humana.
• Refactors o exploración: --allowedTools "Read,Edit,Glob,Grep". Claude puede tocar archivos pero no ejecutar nada destructivo.
• Investigación interna o experimentos: contenedor Docker con --dangerously-skip-permissions activo. Si la lía, docker rm y a otra cosa.
• CI / pipelines: agentes con scope acotado y secrets enmascarados, sin acceso al filesystem completo.

El resultado es velocidad de IA con la disciplina de una agencia con ISO 27001. Las dos cosas no son incompatibles, pero requieren intención.

Resumen y recomendación

claude --dangerously-skip-permissions es una herramienta legítima con un nombre honesto. Lo es para profesionales que trabajan con Claude Code en entornos controlados. No lo es para sesiones casuales, máquinas con acceso a producción o equipos sin gobernanza clara.

Si te encuentras tecleándolo a diario, párate un minuto y pregúntate qué estás ahorrando y qué estás arriesgando. La mayoría de las veces, --allowedTools o permission-mode acceptEdits te dan el 90 % de la velocidad con el 10 % del riesgo.

Y cuando realmente lo necesites, úsalo en un sandbox. Un contenedor, un worktree, una VM. La velocidad sin red es ego. La velocidad con red es ingeniería.

Preguntas frecuentes

¿Es seguro usar claude –dangerously-skip-permissions?

Depende del entorno. En un contenedor efímero o un worktree desechable es seguro. En tu máquina principal con acceso a producción y archivos sensibles, no lo es. Anthropic no llamó al flag «peligroso» por ironía.

¿Cuál es la diferencia entre –dangerously-skip-permissions y –permission-mode bypassPermissions?

Son funcionalmente equivalentes. bypassPermissions es el nombre nuevo y limpio del modo de permisos; el flag --dangerously-skip-permissions mantiene su nombre original como advertencia explícita. Cualquiera de los dos salta todas las confirmaciones.

¿Puedo usar el flag y limitar qué herramientas tiene Claude?

Sí. Aunque saltes los permisos, puedes seguir restringiendo qué tools están disponibles con --allowedTools o con settings.json. Es la combinación recomendada para sesiones autónomas en sandbox: autonomía total dentro de un perímetro definido.

¿Claude Code puede acceder a internet sin permisos?

Solo si el MCP correspondiente está activo. WebFetch, WebSearch o cualquier MCP externo requiere configuración explícita previa. --dangerously-skip-permissions no abre la puerta de internet por sí solo; abre la puerta a usar las MCPs que ya están configuradas.

¿Qué pasa si Claude rompe algo importante en modo dangerously?

Si tu repositorio está en Git y los cambios no se han push-eado, recuperas con git reset o git reflog. Si los cambios sí se push-earon o tocaron archivos fuera de Git (env, credentials, base de datos), la recuperación depende del backup que tengas. Por eso el flag se usa en sandbox.

¿Por qué Anthropic mantiene el flag si es peligroso?

Porque hay casos legítimos (CI, contenedores, demos, batch processing) donde la fricción humana no aporta valor. El nombre del flag es la garantía: lo dejas activo solo si lees lo que escribes. Apagarlo es decisión consciente, no descuido por defecto.

¿Hay algo similar en Cursor, Antigravity, GitHub Copilot u otros agentes?

Sí. Casi todos los IDE agentic modernos tienen un equivalente: «agent mode» en Cursor, «autorun» en Windsurf, «full autonomy» en Antigravity. Cada uno con su matiz, pero el dilema es idéntico — velocidad versus control. La regla del sandbox aplica igual.

---

En Pango Studio integramos Claude Code y agentes IA en proyectos Shopify, ecommerce y operaciones del cliente con políticas de permisos defensivas, certificación ISO 27001 y gobernanza clara. Si te interesa montar un workflow agentic seguro para tu equipo, hablemos.