Accueil / Quand ça déraille

Une commande bloquée

Une commande shell qui ne répond plus se coupe par Ctrl+C sans quitter la session, et le délai qui la fait basculer en tâche de fond est déjà fixé par Claude lui même, pas par un préfixe que vous ajoutez à la main.

Une commande shell lancée depuis Claude Code peut rester figée : aucune sortie, aucune fin. Le premier geste est Ctrl+C, qui tente d'interrompre l'opération en cours sans fermer la session. S'il ne suffit pas, fermer le terminal et relancer avec claude --resume dans le même dossier récupère la conversation entière, seule la commande bloquée est perdue.

Le délai n'est pas un réflexe à ajouter soi même

Une habitude répandue consiste à encadrer chaque commande risquée d'un préfixe timeout tapé à la main. Ce n'est pas le mécanisme réel de l'outil Bash intégré à Claude Code. Ce dernier porte déjà un paramètre timeout que Claude choisit lui même d'ajouter quand il anticipe une commande longue, sans intervention de votre part. Deux variables d'environnement bornent ce comportement : BASH_DEFAULT_TIMEOUT_MS fixe le délai par défaut appliqué à chaque commande, BASH_MAX_TIMEOUT_MS fixe le plafond que Claude ne peut pas dépasser même s'il le demande.

# Deux variables d'environnement lues par Claude Code
BASH_DEFAULT_TIMEOUT_MS=120000   # 2 minutes, valeur par défaut
BASH_MAX_TIMEOUT_MS=600000       # 10 minutes, plafond

Le basculement automatique en tâche de fond

Quand une commande atteint son délai sans avoir terminé, Claude Code ne l'arrête pas : il la bascule de lui même en tâche de fond et continue de travailler pendant qu'elle tourne. Trois familles de commandes échappent à ce basculement automatique et restent bloquantes jusqu'au bout : celles qui commencent par sleep, celles qui contiennent git, et les commandes composées que le parseur de sécurité ne sait pas analyser, comme une expansion du type ${PIPESTATUS[0]}. Pour un processus que vous savez long dès le départ, un serveur de développement ou un build en veille, il vaut mieux demander explicitement le paramètre run_in_background plutôt que d'attendre le déclenchement du timeout.

# Simule une commande longue, sans rien modifier sur ce poste
node -e "setTimeout(() => console.log('travail termine'), 5000)"
# Lancee avec run_in_background, elle rend la main immediatement
# et sa sortie se relit plus tard, sans avoir bloque le fil de conversation

La différence entre les deux situations tient à un seul fait : le timeout protège contre une commande qui ne finira jamais, le passage en tâche de fond libère la conversation pendant qu'une commande qui va finir prend son temps. Confondre les deux fait attendre un chat pour rien, ou couper une commande qui allait aboutir.

Cette même logique de reprise sans perte se retrouve quand c'est la session entière qui se bloque plutôt qu'une seule commande, voir boucles, contexte pollué et redémarrage.