Skip to main content
Claude CodeCodexAI automation

Claude Code et Codex : Surchauffe cachée au repos

Une découverte désagréable : Claude Code et Codex peuvent exécuter des processus cachés en arrière-plan et brûler le CPU même au repos. Pour les entreprises, cela importe non seulement pour la batterie, mais aussi pour les risques dans l'automatisation par IA, où un agent tourne sans surveillance pendant des heures, endommageant potentiellement le matériel.

Contexte technique

Je me suis intéressé à ce cas non pas à cause du drame du « MacBook grillé », mais parce que c'est un problème très concret pour l'automatisation par IA. Si un outil agent maintient un cœur à 100 % en arrière-plan, ce n'est pas seulement l'ordinateur portable qui en pâtit, c'est aussi la confiance dans tout le schéma d'automatisation.

D'après les retours d'utilisateurs, Claude Code et Codex peuvent tous les deux laisser des processus fantômes après une session apparemment normale. En surface, tout est calme, le terminal semble en veille, mais à l'intérieur un processus Node orphelin ou un hook continue de faire tourner le CPU inutilement.

Je regarderais trois points à la fois : les processus Node en arrière-plan, les hooks à démarrage automatique et les sessions trop longues avec un contexte gonflé. Pour Claude Code, la communauté a déjà trouvé des solutions pratiques : tuer les processus Node bloqués, désactiver le hook superpowers, activer le mode streaming, limiter le parallélisme à max-jobs = 2 et nettoyer le contexte avec /clear.

Un aspect pratique m'a particulièrement plu : un délai d'inactivité de 5 minutes. Ce n'est pas une « correction architecturale », mais en tant que soupape de sécurité, cela fonctionne bien. Surtout si vous avez plusieurs canaux d'agents, chacun ayant tendance à laisser une trace derrière lui.

Le conseil « exécutez dans une VM » peut sembler brutal, mais il a du sens. Lorsque je conçois une intégration IA pour de longues sessions, j'essaie presque toujours d'isoler l'environnement d'exécution de l'agent de la machine principale : une VM dédiée, un conteneur, des limites CPU, une surveillance des processus et des règles strictes de terminaison des tâches.

Ce que cela change pour les entreprises

Premièrement : l'exécution locale d'IDE et de CLI agents ne peut plus être considérée comme inoffensive. Si une équipe construit le développement de solutions IA autour des ordinateurs portables des développeurs, la charge cachée se transforme rapidement en surchauffe, bruit, décharge de la batterie et bugs « flottants » étranges.

Deuxièmement : ceux qui intègrent dès le départ l'isolation et l'observabilité gagnent. Ceux qui laissent les agents vivre dans des terminaux sans fin, sans délais, sans limites ni contrôles de surveillance perdent.

Troisièmement : c'est un choc sur le coût total de possession. Un seul processus fantôme coûte moins cher à repérer sur un graphique CPU qu'à devoir gérer par la suite des problèmes matériels, des temps d'arrêt et la perte de temps de l'équipe.

Si vos agents tournent déjà en arrière-plan et que la machine se comporte « bizarrement », je n'attendrais pas un correctif officiel. Vous pouvez rapidement repenser l'architecture pour que l'automatisation avec l'IA ne tue pas les postes de travail : chez Nahornyi AI Lab, nous traitons justement ces cas à la main et construisons une architecture IA sécurisée pour des charges réelles, pas pour une belle démo.

Nous avons précédemment analysé le bug d'auto-analyse de Claude, où l'injection de prompt provoque des processus fantômes et un déni de service. La même dynamique est à l'origine de la surchauffe du MacBook dont il est question maintenant.

Partager cet article