Saltar al contenido principal
Antes de que cualquier herramienta del agente se ejecute, TYBA clasifica la acción en tres niveles. El color decide qué pasa: pasar de largo, esperarte, o ni siquiera ofrecerse.

Verde

Pasa solo. Ni lo ves.

Amarillo

Te espera. Puede convertirse en “siempre” en esta sesión.

Rojo

Te espera. Nunca se convierte en “siempre”.
La regla de fondo es en la duda, amarillo. El verde es una lista cerrada, no una heurística — un comando que nadie previó no pasa solo.

​
Verde

La lista entera. No hay nada más:
Un build no es verde. cargo build, bun install, make — todos amarillos, todos te esperan. Un build ejecuta scripts arbitrarios de las dependencias; la lista verde es solo lectura.
El verde se auto-aprueba siempre, sin opción de desactivarlo. No existe una configuración que fuerce a cat a pedir permiso.

​
Rojo

Fíjate en el detalle del rm: rm -rf, rm -fr y rm -r -f son todos rojos. En cambio rm archivo.txt es amarillo — borrar un archivo dentro del worktree es trabajo normal de un agente. Y el pipe hacia un shell es lo que atrapa curl ... | bash incluso escrito de una forma en la que curl no es el primer token.

​
Salir del worktree lo pinta de rojo

Independientemente del comando, cualquier token que empiece con / o ~/ y resuelva fuera del worktree de la sesión escala a rojo:
Las excepciones son las rutas de sistema que todo comando toca:
Por eso cargo build 2> /dev/null sigue siendo amarillo en vez de escalar. Lo mismo vale para la escritura: grabar dentro del worktree es verde; escaparse de él — por ruta absoluta, por ../, o a través de un symlink que apunta hacia fuera — es rojo.

​
Por herramienta

La red siempre es roja porque es el camino de salida: es por ahí por donde el contenido de tu disco se convertiría en una petición hacia fuera. En Codex, apply_patch se clasifica por la peor ruta que toca — un patch con diez archivos dentro del worktree y uno fuera es rojo.

​
Qué respondes

Cuando algo te está esperando, TYBA notifica y la sesión queda bloqueada hasta la respuesta.
El rojo no tiene “Always”. No es la interfaz escondiendo el botón — el core se niega a memorizar cualquier rojo, así que no hay camino para que esa combinación exista. Al denegar, puedes escribir el motivo. El texto va al agente como razón del rechazo, y él suele intentar otro camino en vez de insistir.

​
Qué significa realmente “Always”

“Always” es de esta sesión y de este comando exacto. Nada de eso va al disco.
  • Vale mientras la sesión viva. Cerraste, murió.
  • Casa con la cadena exacta: liberar cargo test no libera cargo test --release.
  • Nunca acepta un rojo.
Hoy no existe un “permitir siempre” persistente entre sesiones.

​
Qué ni siquiera llega a preguntarse

Un push del agente a main o master es rechazado por el core. No se convierte en un pedido de aprobación, no aparece en el inbox, no tiene botón. El agente recibe el error directo:
El rechazo entiende las variantes — HEAD:main, +main y similares caen en la misma regla.

​
Fail-closed

Si la sesión muere con pedidos pendientes, todos se vuelven denegados. Si el canal de aprobación se rompe, el valor por defecto es denegar. No hay camino en el que el fallo de la infraestructura se convierta en permiso.

​
Ver también