node_modules, sem .env, sem banco. Um agente que sobe ali e roda o projeto não encontra nada.
O .tyba/setup.sh é a resposta:
Quando roda
Uma vez, na criação do worktree, logo depois dogit worktree add e antes de você começar a usar a sessão.
cwdé o worktree, não o repo principal.- Roda numa thread de fundo. Nunca bloqueia a criação da sessão.
- Se falhar, o worktree continua de pé. A falha vira log — o TYBA guarda a saída do script (com o rabo do log, os últimos 400 caracteres, quando dá erro) e a sessão segue.
Sem
.tyba/setup.sh no worktree, nada acontece — nenhum aviso, nenhum erro. Não ter script é o normal.Um script novo não vale nada até você aprovar
Mesma ideia do.tyba/config.toml, pelo mesmo motivo concreto: você clona repositório de terceiros. Um .tyba/setup.sh versionado com efeito automático seria execução de código arbitrário por abrir um projeto.
Então o diálogo de criação de worktree te mostra o script inteiro, com um toggle. Sem o toggle ligado, o arquivo é como se não existisse.
O consentimento é atrelado ao SHA-256 do conteúdo, guardado localmente por (raiz do repo, hash):
1
O TYBA hasheia o conteúdo exato
Um SHA-256 dos bytes.
2
Você lê o script no diálogo e decide
O conteúdo aparece na tela. Não é um resumo — é o script.
3
Seu 'sim' vale para aquele hash, e só
Enquanto o script não mudar, ele vale, e o diálogo já vem com o toggle ligado: “setup.sh já permitido para este repo.”
4
Um byte diferente derruba o consentimento
Alterou, veio um
git pull que mexeu nele, trocou de branch — o hash muda, o consentimento morre, e o TYBA pergunta de novo.O que executa são os bytes consentidos, entregues no stdin do
sh — não o arquivo em disco. Trocar o arquivo entre o seu “sim” e a execução não muda o que roda.O ambiente que ele recebe
O script é código do repo, não seu. Ele não herda o seu shell. O ambiente é montado do zero:
E nada mais. Seu
AWS_SECRET_ACCESS_KEY, seus tokens, seu DATABASE_URL não estão lá.
O
agent.env.allow do .tyba/config.toml não vale aqui. Aquela allowlist é do agente; o setup recebe só a base acima. Se o script precisa de um segredo, ele tem que ir buscar (num arquivo, num keychain) — não vai chegar por variável.PATH vir do shell de login importa na prática: no macOS o app pode nascer pelo launchd, com um PATH mínimo que não tem bun, mise nem /opt/homebrew/bin. O TYBA resolve o PATH do seu login e é esse que o script vê.
Um script real
.tyba/setup.sh
Nada limpa o que o script criou. O banco do exemplo continua lá depois que o worktree é removido — se isso importa pro seu projeto, o
dropdb é problema seu.Editou o script? Commite
O diálogo lê o.tyba/setup.sh da sua cópia de trabalho, e é o hash dela que o seu “sim” carimba. O que roda é o .tyba/setup.sh do worktree — que nasceu no base_sha, ou seja, na versão commitada.
Se você editou o script e não commitou, os dois hashes são diferentes, e o resultado é silencioso: o setup simplesmente não roda. Commite a mudança e crie o worktree de novo.
O que não existe
- Rodar o setup de novo numa sessão existente. É criação de worktree, ou nada.
.tyba/setup.ps1ou equivalente. O contrato éshcom o conteúdo no stdin.- Timeout. Um script que trava fica travado; a sessão sobe do mesmo jeito.
- Painel de logs do setup. O resultado sai como evento da sessão, não como uma aba.
- Consentimento que viaja. Ele é seu, local, por máquina. Máquina nova pergunta de novo — é o comportamento pretendido.
Veja também
Worktrees
Onde o script roda e quando aquela pasta nasce.
.tyba/config.toml
O outro arquivo do repo que pede consentimento por hash.