node_modules, sin .env, sin base de datos. Un agente que arranca ahí y ejecuta el proyecto no encuentra nada.
El .tyba/setup.sh es la respuesta:
Cuándo corre
Una vez, en la creación del worktree, justo después delgit worktree add y antes de que empieces a usar la sesión.
- El
cwdes el worktree, no el repo principal. - Corre en un hilo de fondo. Nunca bloquea la creación de la sesión.
- Si falla, el worktree sigue en pie. El fallo se convierte en log — TYBA guarda la salida del script (con la cola del log, los últimos 400 caracteres, cuando da error) y la sesión sigue.
Sin
.tyba/setup.sh en el worktree, no pasa nada — ningún aviso, ningún error. No tener script es lo normal.Un script nuevo no vale nada hasta que lo apruebes
Misma idea que la del.tyba/config.toml, por el mismo motivo concreto: clonas repositorios de terceros. Un .tyba/setup.sh versionado con efecto automático sería ejecución de código arbitrario por abrir un proyecto.
Así que el diálogo de creación de worktree te muestra el script entero, con un toggle. Sin el toggle activado, el archivo es como si no existiera.
El consentimiento va atado al SHA-256 del contenido, guardado localmente por (raíz del repo, hash):
1
TYBA hashea el contenido exacto
Un SHA-256 de los bytes.
2
Lees el script en el diálogo y decides
El contenido aparece en pantalla. No es un resumen — es el script.
3
Tu 'sí' vale para ese hash, y solo para ese
Mientras el script no cambie, vale, y el diálogo ya viene con el toggle activado: “setup.sh already allowed for this repo.”
4
Un byte diferente tumba el consentimiento
Lo editaste, vino un
git pull que lo tocó, cambiaste de branch — el hash cambia, el consentimiento muere, y TYBA pregunta de nuevo.Lo que se ejecuta son los bytes consentidos, entregados en el stdin de
sh — no el archivo en disco. Cambiar el archivo entre tu “sí” y la ejecución no cambia lo que corre.El entorno que recibe
El script es código del repo, no tuyo. No hereda tu shell. El entorno se monta desde cero:
Y nada más. Tu
AWS_SECRET_ACCESS_KEY, tus tokens, tu DATABASE_URL no están ahí.
El
agent.env.allow del .tyba/config.toml no vale aquí. Aquella allowlist es del agente; el setup recibe solo la base de arriba. Si el script necesita un secreto, tiene que ir a buscarlo (en un archivo, en un keychain) — no le va a llegar por variable.PATH venga del shell de login importa en la práctica: en macOS la app puede nacer por launchd, con un PATH mínimo que no tiene bun, ni mise ni /opt/homebrew/bin. TYBA resuelve el PATH de tu login y ese es el que el script ve.
Un script real
.tyba/setup.sh
Nada limpia lo que el script creó. La base de datos del ejemplo sigue ahí después de que el worktree se elimine — si eso le importa a tu proyecto, el
dropdb es problema tuyo.¿Editaste el script? Commitea
El diálogo lee el.tyba/setup.sh de tu copia de trabajo, y es el hash de esa copia el que sella tu “sí”. Lo que corre es el .tyba/setup.sh del worktree — que nació en el base_sha, o sea, en la versión commiteada.
Si editaste el script y no lo commiteaste, los dos hashes son diferentes, y el resultado es silencioso: el setup simplemente no corre. Commitea el cambio y crea el worktree de nuevo.
Qué no existe
- Volver a correr el setup en una sesión existente. Es creación de worktree, o nada.
.tyba/setup.ps1o equivalente. El contrato esshcon el contenido en el stdin.- Timeout. Un script que se cuelga se queda colgado; la sesión arranca igual.
- Panel de logs del setup. El resultado sale como evento de la sesión, no como una pestaña.
- Consentimiento que viaja. Es tuyo, local, por máquina. Una máquina nueva pregunta de nuevo — es el comportamiento pretendido.
Ver también
Worktrees
Dónde corre el script y cuándo nace esa carpeta.
.tyba/config.toml
El otro archivo del repo que pide consentimiento por hash.