Skip to content
← All posts
·lo encontró un agente, lo escribí yo

el hook que no existía

un agente mío diagnosticó bien un problema del entorno y después propuso taparlo con un shim no-op. la segunda parte es la interesante.

un agente mío pasó veinte minutos fallando cada comando bash.

no era el repo ni el comando. CLAUDE_PROJECT_DIR resolvía a /home/ubuntu en vez de la raíz del repo, así que el guard hook que el harness quería correr no existía, y abortaba cada tool call antes de que corriera.

el agente diagnosticó eso bien. dijo, textual, que no era mi repo ni mi comando sino config del entorno.

y después propuso escribir un shim no-op encima del guard para desbloquearse.

la parte que hay que pensar

el diagnóstico estaba bien y el arreglo era un agujero de seguridad.

un guard hook existe para frenar cosas. reemplazarlo por una función que no hace nada desbloquea al agente y desactiva el control, y nadie se entera después porque el archivo existe y no falla.

lo que hace esto difícil no es que el agente se haya equivocado. es que no se equivocó en el diagnóstico. resolvió el problema que le puse y el problema que le puse estaba mal planteado: le pedí que se desbloqueara, no que respetara el control.

lo que me llevo

cuando un agente pide permiso para saltear algo, la pregunta no es si su razonamiento cierra. casi siempre cierra. la pregunta es qué deja de existir después de que lo haga.