Modo YOLO de OpenCode: ¿existe? Los permisos explicados

Qué significa "modo YOLO" y la respuesta corta para opencode

"Modo YOLO" es el apodo de la comunidad para ejecutar un agente de código con las aprobaciones desactivadas, para que trabaje sin pararse a preguntarte. El nombre viene de herramientas como Claude Code y Codex, donde un único flag apaga las peticiones. La idea cuajó porque capta la sensación: solo se vive una vez, así que apaga las peticiones y deja que el agente corra.

La respuesta corta para opencode es que no existe ese flag. No hay --yolo, no hay --full-auto, no hay ninguna opción de saltarse-nada-peligrosamente. opencode, el agente de terminal de código abierto de SST, no trae ningún bypass de un solo interruptor. En su lugar, lee cuánta libertad le diste desde su configuración de permisos.

Eso significa que la pregunta "¿cómo activo el modo YOLO en opencode?" no tiene un flag como respuesta. La respuesta es un archivo de config. Le dices a opencode qué tipos de acciones se autoejecutan, cuáles preguntan primero y cuáles se deniegan, y se comporta así en cada sesión.

Si lo que de verdad buscas es ejecutar varios agentes de opencode a la vez y no solo uno en full auto, la guía del enjambre de agentes opencode cubre ese lado, y la visión general del enjambre de agentes CLI de IA lo compara en todas las CLI.

Cómo funcionan en realidad los permisos de opencode

La autonomía de opencode vive en la configuración, no en un flag. Los permisos se definen en opencode.json. Hay una config global en ~/.config/opencode/opencode.json, además de config por proyecto y config por agente, así que distintos agentes pueden ejecutarse con distinta cantidad de libertad. Un agente de refactor de confianza puede correr más suelto que uno general, y tu repo del trabajo puede quedarse más estricto que un proyecto paralelo.

Los valores siguen un patrón de allow, ask, deny por tipo de acción. Decides, por ejemplo, que las ediciones de archivos se ejecutan solas mientras los comandos de shell se paran a preguntar primero. Una config mínima tiene esta pinta:

{
  "permission": {
    "edit": "allow",
    "bash": "ask"
  }
}

Tómalo como ilustrativo. Las claves y los valores exactos evolucionan entre versiones de opencode, y el esquema crece con el tiempo, así que la documentación oficial de opencode es la fuente de verdad para lo que admite tu versión instalada. No copies una config que viste en un post antiguo sin contrastarla con la documentación actual.

Poner todo en allow es lo más parecido que tiene opencode a un modo YOLO. Hace que opencode lea, escriba y ejecute comandos por su cuenta, sin ninguna petición de por medio. La velocidad es real, y el riesgo también: una config todo-en-allow conlleva exactamente el mismo peligro que cualquier flag de bypass, porque no queda nada que frene un comando destructivo.

En qué se diferencia de Claude Code y Codex

Claude Code y Codex exponen un bypass de un solo flag. Claude Code tiene --dangerously-skip-permissions, Codex tiene --full-auto. Tecleas el flag y las aprobaciones se apagan para esa tirada. La guía de Turbo Mode YOLO de Claude Code de CodeAgentSwarm recorre ese modelo en detalle.

El enfoque por configuración de opencode es, siendo justos, más sensato. El estado permisivo es explícito, versionable y acotado: vive en un archivo que puedes leer, commitear y compartir, en lugar de un flag que alguien teclea con prisa y olvida. Ves de un vistazo qué acciones autoaprueba tu proyecto, y mantienes esa política consistente en cada sesión en vez de depender de acordarte de añadir o quitar un flag cada vez.

Los riesgos reales de permitir todo

Esto no son hipótesis. Con todo puesto en allow, opencode se ejecuta sobre un repo en uso con un historial de Git de verdad y datos de verdad, y cualquiera de estas cosas puede pasar dentro de una sola sesión, sin ninguna petición que la frene antes.

• Push de Git a la rama equivocada - opencode decide hacer commit y push de trabajo a medias a main, o hace force-push y machaca a un compañero.
• Borrado de archivos o directorios - Una instrucción malinterpretada se convierte en rm -rf sobre una ruta que no querías eliminar.
• Comandos de shell irreversibles - DROP TABLE, docker system prune o cualquier cosa que no se pueda deshacer una vez se ejecuta.
• Instalar la dependencia equivocada - npm install sobre un paquete con typosquatting o comprometido que a simple vista parecía correcto.
• Llamadas de red no deseadas - Golpear endpoints de producción, enviar datos a servicios externos o disparar webhooks que no esperabas.
• Sobrescribir trabajo sin commitear - opencode edita archivos que estabas tocando y tu trabajo sin commitear desaparece antes de que te des cuenta.

El full auto no es malo en sí. Es el ajuste correcto para mucho trabajo. El riesgo viene de poner todo en allow sin mantener frenadas las operaciones de verdad peligrosas. La siguiente sección va justo sobre eso.

Cómo ejecutar opencode en full auto con seguridad

Hay varios enfoques, del menos controlado al más. El objetivo es el mismo en todos: mantener la velocidad del full auto en las operaciones seguras sin dejar nunca que un comando destructivo se ejecute sin supervisión.

Método 1: permitir todo en trabajo desechable

Pon todos los permisos en allow y deja que opencode corra sin supervisión. Esto va bien para proyectos de pruebas y ramas desechables, donde confías en que nada destructivo puede importar y puedes tirarlo todo a la basura. En un repo real con historial de verdad, correr del todo abierto es una apuesta, porque una sola instrucción malinterpretada alcanza Git, borrados y la red sin ninguna petición de por medio.

Método 2: una config de permisos selectiva (el punto dulce)

Un punto de partida mejor es una config selectiva. Permite las ediciones y lecturas de archivos para que el trabajo rutinario pase de largo, pero mantén los comandos de shell, o al menos los destructivos, en ask. Ponlo por proyecto o por agente, para que un agente de refactor de confianza corra más suelto que uno general, y tu repo principal se quede más estricto que un proyecto de pruebas. Luego mete tus normas de la casa en AGENTS.md, el archivo de instrucciones común entre herramientas, para que cada sesión herede la misma guía sin que la repitas.

Este es el punto dulce porque conserva las partes del full auto que de verdad ahorran tiempo mientras frena el puñado de acciones que causan daño real. A diferencia de un solo flag de bypass, no te obliga a elegir entre preguntar por todo y no preguntar por nada.

Método 3: ejecutar la config permisiva dentro de CodeAgentSwarm (recomendado para enjambres)

Que quede claro: CodeAgentSwarm no expone un interruptor de Turbo Mode para opencode. El Turbo Mode existe para Claude Code y Codex, que tienen un flag de bypass que activar. opencode no tiene ese flag, así que su propia config de permisos es el plano de control y no hay nada que un interruptor pueda cambiar. Lo que CodeAgentSwarm añade en su lugar es supervisión alrededor de tu config permisiva de opencode, para que el trabajo en full auto nunca sea una caja negra.

Esto es lo que te da esa supervisión por encima de opencode:

• Varios terminales de opencode en una ventana - Ejecuta todo un enjambre de opencode en paralelo en lugar de hacer malabares con ventanas sueltas.
• Diffs de archivos en vivo por terminal - Observa exactamente qué está cambiando cada agente de opencode en tiempo real, para que una config permisiva nunca corra sin verse.
• Notificaciones de escritorio - Recibe un aviso cuando un agente termina o se atasca esperando input, en vez de vigilar cada terminal.
• Títulos dinámicos - Cada terminal muestra en qué está trabajando su agente, para que distingas el enjambre de un vistazo.
• Historial buscable y reanudable - Audita qué hizo un agente después de los hechos y retoma una sesión con el propio soporte de reanudación de opencode.

La combinación de una config selectiva más supervisión en tiempo real es lo que hace viable un enjambre permisivo de opencode. La config decide qué se autoejecuta; CodeAgentSwarm se asegura de que puedas ver y auditar cada una de esas tiradas. Para ejecutar muchos agentes de opencode a la vez, la guía de ejecutar múltiples sesiones de opencode cubre el montaje de principio a fin.

Buenas prácticas para tiradas de opencode en full auto

Sea cual sea el método que uses, estos hábitos mantienen fuera de la mesa los peores accidentes del full auto:

• Trabaja siempre en una rama de feature, nunca en main. Si opencode la lía, tiras la rama. Si la lía en main, lo nota todo el equipo.
• Haz commit antes de empezar una tirada permisiva. Un punto de restauración limpio significa que git checkout . te devuelve al instante si algo sale mal.
• Mantén en ask las acciones destructivas de Git y de shell. Aunque todo lo demás esté en allow, push, force-push, merge, borrado de ramas y los comandos de shell irreversibles deberían pararse a pedir confirmación. Son las acciones de mayor impacto y más difíciles de deshacer.
• Mete las instrucciones permanentes en AGENTS.md. Las normas de la casa en el archivo de instrucciones común hacen que cada sesión de opencode herede los mismos guardarraíles sin que los repitas.
• Vigila el diff en vivo. Una vista de cambios de archivos por terminal convierte una config permisiva de caja negra en algo que de verdad puedes supervisar.
• Mantén los prompts acotados. "Refactoriza el middleware de auth para usar JWT" es mucho más seguro en full auto que "mejora el código". Cuanto más estrecho el alcance, menos margen tiene opencode para irse por las ramas.