Aquí no hay nada que tengas que configurar. No existe una pantalla de hooks, no existe un archivo de hooks tuyo, no existe una preferencia para activarlo o desactivarlo.Esto es doc de cómo funciona, para quien quiera entender de dónde sale el inbox de aprobaciones. Si solo quieres usar el producto, puedes saltártelo.
El problema
Un agente que corre suelto es un proceso que decide solo. Lee lo que quiere, escribe lo que quiere, y tú te enteras después — leyendo el diff, o no leyéndolo. Para que exista un gate, alguien tiene que ser avisado antes de que cada herramienta corra, y tiene que poder retener la ejecución hasta que llegue la respuesta. Eso no se puede hacer raspando la pantalla: cuando el texto apareció en la terminal, el comando ya corrió. Claude Code y Codex tienen un mecanismo para esto — hooks. TYBA usa ese mecanismo.Qué hace TYBA
Cada vez que una sesión de agente arranca, TYBA inyecta una configuración de hooks en el agente y abre un canal local para recibir los eventos.1
Monta la configuración
Un puñado de eventos apuntando a un único comando: el propio binario de TYBA, en un modo especial (
_hook).2
La inyecta en el agente
Claude Code — un
hooks.json en un directorio privado de la sesión, pasado con --settings.Codex — sin archivo: los hooks van como --config en la línea de comando, cada uno con un hash que Codex comprueba para aceptarlos sin preguntarte.3
Abre el canal
Un socket local — AF_UNIX en macOS y Linux, un named pipe en Windows, porque un socket unix no atraviesa la jaula de allí. La ruta llega al agente en la variable
TYBA_HOOK_SOCKET.4
El agente llama de vuelta
Antes de usar una herramienta, el agente ejecuta el comando del hook. Este re-ejecuta el binario de TYBA, que lee el socket de la variable y entrega el evento a la app.
Los eventos
En Codex hay además
PermissionRequest, que es como pide permiso.
Por qué PreToolUse es el producto entero
Cuando el agente va a usar una herramienta, el hook dispara antes y se queda colgado esperando respuesta. Esa espera es la que da tiempo a que exista una decisión.
TYBA clasifica la acción en verde, amarillo o rojo. El verde vuelve permitido al instante, sin que lo veas. El amarillo y el rojo bloquean el hook y se convierten en un ítem del inbox — el agente queda literalmente parado en mitad de la llamada, porque el proceso del hook todavía no ha retornado.
Tú respondes, el hook retorna permitido o denegado, y el agente sigue o se lleva la negativa.
El timeout de
PreToolUse es de 86.400 segundos — 24 horas. No es una exageración: es el número que dice “espera al usuario el tiempo que haga falta”. Los demás eventos, que solo avisan, tienen 60 segundos.Mientras tanto, Claude Code muestra “Waiting for approval in TYBA…” en su propia pantalla.De dónde viene el status de la sesión
Del mismo canal. Los eventos de hook se convierten en status directamente:
Esto es dato estructurado, no texto raspado de la pantalla. Ninguna heurística mira lo que el agente dibujó en la terminal para adivinar si terminó.
El OSC 133 sí existe, pero sirve para otra cosa: detectar que un agente está corriendo en un shell común, para que aparezca el composer. Eso es una pista de visualización, nunca autorización — y un shell no tiene gate.
Esto no es el consentimiento del repositorio
Confusión fácil, y las dos cosas no tienen relación:
Los hooks son maquinaria interna: sin ellos no hay gate, así que no hay un botón para apagarlos — apagarlos sería quitar la única cosa que sujeta al agente.
El
.tyba/config.toml es contenido de terceros, vino junto con un git clone, y por eso no vale nada hasta que lo apruebes. Las reglas están en Configuración del repositorio.
Cuando el canal se rompe
Fail-closed. Una sesión que muere con pedidos pendientes los tiene todos denegados; un canal roto deniega. No existe un camino en el que un fallo de infraestructura se convierta en permiso — el mismo principio descrito en Clasificación de riesgo.Ver también
Clasificación de riesgo
Lo que
PreToolUse hace con cada comando.Agente por SSH
Lo que pasa cuando el hook no existe.