vm-playground — Claude Code se auto-relanza en tmux (cron watchdog)

Mismo mecanismo que ya corría en ctunlinux y en pop-os (t640-pop) — ver Herramientas CLI de escritorio — replicado en vm-playground el 2026-09-06 a petición explícita de Esteban. ~/.local/bin/tmux-claude-watchdog.sh corre por crontab de usuario cada minuto (`* * * * * ~/.local/bin/tmux-claude-watchdog.sh

~/.local/state/tmux-claude-watchdog.log 2>&1), sin depender de systemd —userni deloginctl enable-linger` — el daemon de cron del sistema es independiente de que haya una sesión de usuario logueada.

El script recorre una lista de targets (sesión_tmux:directorio_de_trabajo:--name) y, por cada uno, revisa tmux has-session: si la sesión no existe la crea; si existe, chequea tmux list-panes -F '#{pane_current_command}' — si el pane no tiene literalmente claude como proceso activo (se cerró, truena, o quedó en un shell suelto), le manda de nuevo las teclas para relanzarlo. En vm-playground corre un solo target:

claude-scratch:/home/ubuntu/claude-scratch:vm-playground_claude-scratch

Sesión tmux claude-scratch, directorio ~/claude-scratch, Claude Code lanzado con --name vm-playground_claude-scratch. Cada relanzamiento arranca una conversación nueva y vacía, nunca retoma la anterior — misma decisión explícita que en ctunlinux al generalizar el script ahí.

Por qué cron y no un .service/.timer de systemd --user (ya evaluado y descartado en ctunlinux, mismo razonamiento aplica acá): en cuanto tmux new-session -d crea la sesión, el proceso que systemd rastrea (el cliente tmux) termina y el control pasa al demonio de tmux, ajeno al árbol de systemd — si claude truena adentro después, systemd nunca se entera. Restart= no puede cubrir ese caso bajo ningún diseño de unit; la única solución real es un script de polling externo, y cron ya lo resuelve sin necesidad de una segunda pieza de infraestructura.

Verificado end-to-end el mismo día: tmux kill-session -t claude-scratch seguido de tmux has-session en loop confirmó que el siguiente tick de cron recreó la sesión (y el proceso claude dentro) sin intervención manual, con el evento registrado en ~/.local/state/tmux-claude-watchdog.log.

No vigila la sesión 3 (otra sesión de tmux corriendo Claude Code en /home/ubuntu, preexistente en este host) — decisión explícita al instalar el watchdog: solo claude-scratch es el target administrado por este mecanismo.

Véase también

• ctunlinux — servidor Docker de Trivasa BI — origen del script y del razonamiento completo cron-vs-systemd
• Herramientas CLI de escritorio — mismo patrón en pop-os (t640-pop)
• claude-skills — repo de skills propios de Claude Code — otro mecanismo de automatización de Claude Code que también corre en vm-playground, pero vía systemd --user + timer (caso distinto: sincroniza archivos, no vigila un proceso vivo)