Cómo ejecutar Claude Code de forma autónoma durante horas sin supervisión constante

Dejé Claude Code ejecutándose durante la noche con una tarea real. Probando AIdaemon, mi agente de IA personal, a través de la interfaz web de Telegram. Lo revisé durante el día, lo dejé seguir toda la noche, y para la mañana siguiente había estado funcionando durante más de 27 horas. 84 tareas completadas. Encontró errores, arregló el código, volvió a probar y pasó a pruebas más difíciles. Todo sin que yo tocara nada. Estoy en el plan Claude Code 20x, que te da suficiente capacidad para ejecutar sesiones como esta.

La configuración que hizo esto posible son tres indicadores (flags) y un buen archivo de prompt.

Omita los prompts de permiso

Claude Code normalmente pide confirmación antes de ejecutar comandos o editar archivos. Eso está bien cuando estás presente. Pero para las ejecuciones nocturnas, cada prompt de permiso es una parada en seco. La sesión se queda ahí esperando a que hagas clic en "permitir".

claude --dangerously-skip-permissions

El nombre del indicador está diseñado para asustar. Significa que Claude Code ejecuta cada llamada a herramienta sin preguntar. No usaría esto en una máquina con secretos de producción. Sin embargo, en una máquina de desarrollo con una tarea acotada, es lo que hace posibles las ejecuciones desatendidas.

Dale un navegador

Necesitaba que Claude Code interactuara con una aplicación web. Estaba probando el bot de Telegram de AIdaemon a través de Telegram Web, y Claude Code por sí solo no puede hacer eso ya que reside en la terminal.

El indicador --chrome lo conecta a Chrome a través de la extensión Claude in Chrome MCP. Puede navegar por páginas, hacer clic en botones, rellenar formularios, leer contenido, tomar capturas de pantalla. Combina ambos indicadores y obtienes algo que puede escribir código en la terminal y probarlo en el navegador.

claude --chrome --dangerously-skip-permissions

En mi caso, Claude Code enviaba un mensaje a AIdaemon a través de Telegram Web, leía la respuesta, decidía si el agente había hecho lo correcto y luego arreglaba el código si no lo había hecho. Luego intentaba lo mismo de nuevo para confirmar.

Mantenlo en ejecución con Ralph Loop

Si simplemente inicias Claude Code con un prompt grande, termina y sale. O cree que ha terminado y sale. Eso está bien para una tarea rápida, pero inútil para algo que debería durar horas.

Ralph Loop es un plugin de Claude Code que soluciona esto. Instala un gancho de parada (stop hook). Cuando Claude intenta salir, el gancho lo intercepta y vuelve a introducir el mismo prompt. Cada iteración comienza una conversación nueva con el mismo prompt, pero Claude puede ver el estado actual de los archivos y el historial de git. Averigua lo que se ha hecho y decide qué hacer a continuación. El nombre proviene de la técnica Ralph Wiggum de Geoffrey Huntley. La idea original era muy simple, un bucle while true de bash que sigue introduciendo un archivo de prompt en un agente de IA hasta que lo consigue. Fuerza bruta se encuentra con persistencia, como el personaje de Los Simpson que sigue adelante sin importar nada. A Anthropic le gustó lo suficiente como para lanzar un plugin Ralph Wiggum como parte de Claude Code.

/ralph-loop "tu prompt de tarea aquí" --completion-promise "DONE"

El --completion-promise es la única forma de salir. Claude solo puede romper el bucle emitiendo esa cadena exacta. También puedes establecer --max-iterations, como red de seguridad.

Escribe un prompt real

Las herramientas anteriores son la maquinaria. Pero el prompt determina si obtienes una hora de trabajo útil o veintisiete. "Prueba mi aplicación y corrige errores" te dará quizás una hora antes de que Claude declare la victoria después de una sola corrección.

Para cualquier cosa seria, escribo un archivo markdown. Arquitectura, objetivos, restricciones, lo que realmente significa "hecho". Luego lo paso a ralph-loop.

/ralph-loop "$(cat task-prompt.md)" --completion-promise "DONE"

Mi prompt para la sesión de 27 horas era algo parecido a esto.

# Tarea. Probar y reforzar el agente de Telegram AIdaemon

## Contexto
AIdaemon es un agente de IA multipropósito accesible a través de Telegram.
La interfaz web está en https://web.telegram.org/k/#@aidaemon_coding_bot

## Objetivos
- Desafiar al agente con tareas progresivamente más difíciles
- No solo probar las rutas felices. Probar casos límite, entradas mal formadas,
  operaciones complejas de varios pasos
- Cuando algo falle, arreglar el código subyacente
  (no un parche para ese caso específico)
- Volver a probar después de cada corrección para confirmar que funciona Y que nada más se rompió

## Notas de arquitectura
(rutas de archivos relevantes, cómo el agente procesa los mensajes,
módulos clave, esquema de base de datos, lo que Claude necesite)

## Criterios de éxito
- Todas las operaciones básicas funcionan de manera fiable
- Casos límite manejados con elegancia
- Los mensajes de error son útiles, no crípticos
- Sin regresiones de correcciones anteriores
- Emitir DONE cuando todo lo anterior sea cierto

Sin notas de arquitectura, Claude desperdicia iteraciones tratando de entender la base de código. Sin criterios de éxito claros, no sabe cuándo parar. Sin la instrucción de hacer correcciones genéricas, escribe una sentencia if para una entrada específica y sigue adelante.

Qué pasó durante 27 horas

Ejecuté el comando y me fui a dormir.

La primera hora fue de conceptos básicos. Mensajes simples al bot, comprobando respuestas. Luego comenzó a escalar por su cuenta. Tareas de refactorización de varios archivos. Recuperación de errores con entradas rotas. Encontró una vulnerabilidad de inyección de prompt, escribió una defensa y luego probó una variante de inyección más difícil para verificar si la defensa se mantenía.

Para la prueba 88, había hecho que el agente construyera un analizador sintáctico (parser) JSON desde cero con 79 casos de prueba. Antes había corregido los límites de ping de notificación en segundo plano, resuelto errores de resolución de nombres de herramientas y detectado un problema de UX donde la mecánica interna se mostraba en mensajes dirigidos al usuario.

Las correcciones fueron reales, no superficiales. El "perfil barato" usaba first_fallback en lugar del modelo predeterminado, por lo que arregló la lógica de configuración. La resolución del nombre de la herramienta de saturación de lectura fallaba, por lo que añadió un retroceso en cascada (cascade fallback) para todas las profundidades, no solo para la que falló.

84 tareas en total. Pruebas, correcciones, nuevas pruebas. Todo autónomo.

Lo que compartiría con alguien que intente esto

Ejecuté algunas sesiones con prompts de una sola línea antes de esta. Se quedaron sin impulso después de una o dos horas. La sesión de 27 horas continuó porque el archivo de prompt tenía suficiente contexto para que Claude se mantuviera encaminado a través de docenas de iteraciones.

Decirle a Claude que hiciera correcciones genéricas en lugar de parches específicos marcó una diferencia real. Sin eso, escribe el código mínimo para que pase la prueba actual. Con eso, las correcciones también previnieron errores relacionados.

El acceso al navegador detectó cosas que las pruebas unitarias no habrían detectado. Peculiaridades de la interfaz de usuario, problemas de sincronización, problemas de formato. --chrome permitió a Claude hacer pruebas de extremo a extremo reales en lugar de solo ejecutar código de forma aislada.

Revisé todos los cambios después. La mayoría fueron buenos. Un par estaban excesivamente diseñados, y una refactorización tocó más archivos de los necesarios. Pero en general, docenas de errores reales encontrados y corregidos, cada uno confirmado con una nueva prueba.

Si quieres probarlo, instala el plugin Ralph Loop, escribe un archivo de prompt adecuado y empieza poco a poco. --max-iterations 10 en una tarea contenida. Mira cómo va antes de escalar.