Comment exécuter Claude Code de manière autonome pendant des heures sans surveillance

J'ai laissé Claude Code tourner toute la nuit sur une tâche réelle. Je testais AIdaemon, mon agent IA personnel, via l'interface web de Telegram. Je l'ai vérifié pendant la journée, l'ai laissé continuer la nuit, et le lendemain matin, il tournait depuis plus de 27 heures. 84 tâches terminées. Il a trouvé des bugs, corrigé le code, retesté, et est passé à des tests plus difficiles. Tout cela sans que je touche à rien. Je suis sur le forfait Claude Code 20x, ce qui vous donne suffisamment de capacité pour réellement exécuter des sessions comme celle-ci.

La configuration qui a rendu cela possible se résume à trois drapeaux (flags) et un bon fichier de prompt.

Ignorer les invites de permission

Claude Code demande normalement une confirmation avant d'exécuter des commandes ou de modifier des fichiers. C'est bien quand vous êtes là. Mais pour les exécutions nocturnes, chaque invite de permission est un arrêt net. La session reste là à attendre que vous cliquiez sur « autoriser ».

claude --dangerously-skip-permissions

Le nom du drapeau est effrayant à dessein. Cela signifie que Claude Code exécute chaque appel d'outil sans demander. Je n'utiliserais pas cela sur une machine contenant des secrets de production. Sur une machine de développement avec une tâche délimitée, cependant, c'est ce qui rend les exécutions sans surveillance possibles.

Donnez-lui un navigateur

J'avais besoin que Claude Code interagisse avec une application web. Je testais le bot Telegram d'AIdaemon via Telegram Web, et Claude Code seul ne peut pas le faire car il réside dans le terminal.

Le drapeau --chrome le connecte à Chrome via l'extension Claude in Chrome MCP. Il peut naviguer sur les pages, cliquer sur des boutons, remplir des formulaires, lire du contenu, prendre des captures d'écran. Combinez les deux drapeaux et vous obtenez quelque chose qui peut écrire du code dans le terminal et le tester dans le navigateur.

claude --chrome --dangerously-skip-permissions

Dans mon cas, Claude Code envoyait un message à AIdaemon via Telegram Web, lisait la réponse, décidait si l'agent avait fait ce qu'il fallait, et allait corriger le code si ce n'était pas le cas. Puis il essayait la même chose à nouveau pour confirmer.

Maintenez l'exécution avec Ralph Loop

Si vous lancez simplement Claude Code avec un gros prompt, il termine et se ferme. Ou pense avoir terminé et se ferme. C'est bien pour une tâche rapide mais inutile pour quelque chose qui devrait prendre des heures.

Ralph Loop est un plugin pour Claude Code qui résout ce problème. Il installe un crochet d'arrêt (stop hook). Lorsque Claude essaie de se terminer, le crochet l'intercepte et renvoie le même prompt. Chaque itération commence une nouvelle conversation avec le même prompt, mais Claude peut voir l'état actuel des fichiers et l'historique git. Il détermine ce qui a été fait et décide de la suite. Le nom vient de la technique Ralph Wiggum de Geoffrey Huntley. L'idée originale était d'une simplicité désarmante : une boucle while true bash qui alimente continuellement un fichier de prompt dans un agent IA jusqu'à ce qu'il réussisse. La force brute rencontre la persistance, comme le personnage des Simpsons qui continue quoi qu'il arrive. Anthropic a trouvé cela suffisamment intéressant pour intégrer un plugin Ralph Wiggum dans le cadre de Claude Code.

/ralph-loop "votre prompt de tâche ici" --completion-promise "DONE"

Le --completion-promise est la seule issue. Claude ne peut interrompre la boucle qu'en affichant cette chaîne exacte. Vous pouvez également définir --max-iterations, comme filet de sécurité.

Écrire un vrai prompt

Les outils ci-dessus sont la machinerie. Mais le prompt détermine si vous obtenez une heure de travail utile ou vingt-sept. « Testez mon application et corrigez les bugs » vous donnera peut-être une heure avant que Claude ne déclare victoire après une seule correction.

Pour tout ce qui est sérieux, j'écris un fichier markdown. Architecture, objectifs, contraintes, ce que signifie réellement « terminé ». Puis je le passe à ralph-loop.

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

Mon prompt pour la session de 27 heures ressemblait à ceci.

# Tâche. Tester et renforcer l'agent Telegram AIdaemon

## Contexte
AIdaemon est un agent IA polyvalent accessible via Telegram.
L'interface web se trouve à l'adresse https://web.telegram.org/k/#@aidaemon_coding_bot

## Objectifs
- Mettre l'agent au défi avec des tâches progressivement plus difficiles
- Ne pas tester uniquement les chemins heureux. Essayer les cas limites, les entrées malformées,
  les opérations complexes en plusieurs étapes
- Lorsqu'un problème survient, corriger le code sous-jacent
  (pas un pansement pour ce cas spécifique)
- Retester après chaque correction pour confirmer que cela fonctionne ET que rien d'autre n'a été cassé

## Notes d'architecture
(chemins de fichiers pertinents, comment l'agent traite les messages,
modules clés, schéma de base de données, tout ce dont Claude a besoin)

## Critères de succès
- Toutes les opérations de base fonctionnent de manière fiable
- Les cas limites sont gérés avec élégance
- Les messages d'erreur sont utiles, pas cryptiques
- Aucune régression par rapport aux corrections précédentes
- Afficher DONE lorsque tout ce qui précède est vrai

Sans notes d'architecture, Claude perd des itérations à essayer de comprendre la base de code. Sans critères de succès clairs, il ne sait pas quand s'arrêter. Sans l'instruction de faire des corrections génériques, il écrit une instruction if pour une entrée spécifique et passe à autre chose.

Ce qui s'est passé au cours des 27 heures

J'ai lancé la commande et je suis allé me coucher.

La première heure concernait les bases. Messages simples au bot, vérification des réponses. Ensuite, il a commencé à monter en puissance de lui-même. Tâches de refactorisation sur plusieurs fichiers. Récupération d'erreurs avec des entrées cassées. Il a trouvé une vulnérabilité d'injection de prompt, a écrit une défense, puis a testé une variante d'injection plus difficile pour vérifier si la défense tenait bon.

Au test 88, il avait l'agent en train de construire un analyseur JSON à partir de zéro avec 79 cas de test. Plus tôt, il avait corrigé les plafonds de ping de notification en arrière-plan, résolu des bugs de résolution de noms d'outils, et détecté un problème d'UX où des mécanismes internes apparaissaient dans les messages destinés aux utilisateurs.

Les corrections étaient réelles, pas superficielles. Le « profil bon marché » utilisait first_fallback au lieu du modèle par défaut, il a donc corrigé la logique de configuration. La résolution du nom de l'outil de saturation de lecture échouait, il a donc ajouté une résolution en cascade pour toutes les profondeurs, pas seulement celle qui était cassée.

84 tâches au total. Tests, corrections, retests. Tout de manière autonome.

Ce que je partagerais avec quelqu'un qui essaie ceci

J'ai exécuté quelques sessions avec des prompts en une seule ligne avant celle-ci. Elles se sont essoufflées après une heure ou deux. La session de 27 heures a continué car le fichier de prompt contenait suffisamment de contexte pour que Claude reste concentré sur des dizaines d'itérations.

Dire à Claude de faire des corrections génériques au lieu de correctifs spécifiques a fait une réelle différence. Sans cela, il écrit le code minimum pour que le test actuel passe. Avec cela, les corrections ont également empêché des bugs connexes.

L'accès au navigateur a permis de détecter des choses que les tests unitaires n'auraient pas vues. Des bizarreries d'interface utilisateur, des problèmes de synchronisation, des problèmes de formatage. --chrome a permis à Claude d'effectuer de véritables tests de bout en bout au lieu de simplement exécuter du code de manière isolée.

J'ai examiné tous les changements après. La plupart étaient bons. Quelques-uns étaient trop complexes, et un refactoring a touché plus de fichiers que nécessaire. Mais dans l'ensemble, des dizaines de vrais bugs trouvés et corrigés, chacun confirmé par un retest.

Si vous voulez essayer, installez le plugin Ralph Loop, écrivez un fichier de prompt approprié, et commencez petit. --max-iterations 10 sur une tâche contenue. Voyez comment cela se passe avant de passer à l'échelle supérieure.