20260917 #8 — El agente dijo que esperaba y no esperó

Esta mañana, antes de lanzar los forks que refinaron los tickets de esta nota, exporté a mano una variable de entorno desde afuera del script que arranca el loop. La pongo así cada vez que corro este proyecto. Hace cinco noches esa variable no existía en ningún lado, y no saberlo costó USD 2.79 y cero tickets terminados.

Voy a esperar

La madrugada del 12 de septiembre, en el proyecto del chatbot, corrió el loop en paralelo por primera vez: dos tickets a la vez, cada uno con su coordinator. Cada coordinator delegó el trabajo en un coder, que arrancó en background mientras seguía su turno. Los dos escribieron casi lo mismo antes de cerrar: "voy a esperar la notificación de finalización", con estado success. Ningún error a la vista; el proceso reportó que estaba esperando.

No estaba esperando: había terminado y no iba a volver. Diez minutos después — seiscientos segundos — el proceso que sí esperaba cortó a los dos coders con el mismo mensaje: Background tasks still running after 600s; terminating. Set CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0 to wait indefinitely. El registro quedó sin tocar. Costo: USD 2.79. Dos coordinators, cero tickets hechos.

Diez minutos

Correr algo en modo headless — sin terminal interactiva, claude -p responde una sola vez — permite delegar en un agente "en background": arranca a otro y sigue con lo suyo mientras el segundo trabaja aparte, y se entera cuando el segundo avisa que terminó. Sirve para una pregunta corta. Pero el harness trae un tope de espera por defecto — diez minutos —, pensado para una consulta puntual, no para un ciclo que escribe, revisa y corrige código. Si tarda más, el harness no avisa que se cansó: mata el proceso de abajo, y el de arriba ya no está para enterarse.

Dieciocho minutos después de arrancar esa corrida llegó el arreglo: una línea de código, con cuatro de comentario, en el script del loop. La corrida siguiente terminó diez tickets esa madrugada.

Una línea, un repo

Lo notable no es la corrección — el mensaje de error la sugiere. El mismo tope ya había cortado una corrida en este proyecto un día antes, con USD 0.81 perdidos, y quedó anotado como pendiente en vez de resuelto ahí mismo. Sigue pendiente seis días después. De once scripts de loop en el ecosistema de proyectos con los que trabajo — nueve activos más los dos moldes de los que nace cada proyecto nuevo —, solo uno tiene la línea: el que la sufrió esa madrugada. Un proyecto que arranca hoy nace sin el arreglo.

Un fix de una línea tiene el mismo problema de propagación que una convención de diez páginas: si nada lo empuja entre repos, alguien tiene que acordarse de empujarlo. ¿Cuántos fixes de una línea tenés guardados en un solo lugar, con el mismo bug esperando en los demás?

Tags: subagentes en background · modo headless · tope de espera · costo sin resultado · propagación de fixes