Mon Mac tuait mes agents, alors j'ai construit Agent Session Pilot

Tu confies à Claude Code un refactoring de 20 minutes. Tu fermes ton MacBook et tu vas chercher un café. Tu reviens, tu ouvres le capot, et l'agent est là où tu l'as laissé : arrêté à mi-chemin, rien de terminé.

Le 28 décembre 2025, j'ai écrit un petit script pour régler ça. Dix mois et 58 releases plus tard, ce script est devenu l'app par laquelle je pilote tous mes agents, et depuis aujourd'hui elle a un nouveau nom : Agent Session Pilot. L'acronyme reste ASP, la commande reste asp. Tu l'as peut-être croisée sous le nom d'Agents Sleep Preventer, ou avant ça de Claude Sleep Preventer.

Voici ce qu'elle fait, comment elle marche, et pourquoi l'ancien nom devait disparaître.

#Pourquoi caffeinate ne suffit pas

La première réponse de tout le monde, c'est caffeinate. Claude Code le lance déjà : regarde ps pendant qu'il travaille, tu trouveras caffeinate -i -t 300 sous le processus claude. Ça empêche la veille par inactivité. Ferme le capot et le Mac s'endort quand même.

Ce qui tient capot fermé, c'est ça :

sudo pmset -a disablesleep 1
# et plus tard, sans faute :
sudo pmset -a disablesleep 0

disablesleep n'apparaît même pas dans man pmset. J'ai essayé de m'en passer : pendant deux mois, j'ai utilisé l'API propre d'Apple, IOPMAssertion, puis je suis revenu à pmset en mars, plus fiable capot fermé.

La commande, c'est la partie facile. Le flag est global et reste actif jusqu'à ce que quelque chose le coupe. Le vrai travail, c'est de le couper au bon moment, à chaque fois. Sinon ton Mac reste allumé dans ton sac.

#Les hooks décident quand

Claude Code et Codex ont tous les deux des hooks de cycle de vie, et ASP s'y branche. Sur Claude Code :

UserPromptSubmit  ->  asp start        session active, veille coupée
PreToolUse        ->  asp refresh      toujours vivant
PostToolUse       ->  asp refresh
PreCompact        ->  asp refresh
SubagentStart     ->  asp refresh
SubagentStop      ->  asp refresh
Stop              ->  asp stop         le dernier rend la veille
StopFailure       ->  asp interrupted  erreur réseau ou API
Notification      ->  asp attention    l'agent a besoin de toi

Deux cas rendent ça moins simple qu'il n'y paraît :

• Le tour se termine, pas le travail. Stop se déclenche à la fin d'un tour même si des sous-agents ou des commandes en arrière-plan tournent encore. asp stop regarde donc l'arbre de processus de l'agent et garde le Mac éveillé tant qu'il est occupé.
• Le hook n'arrive jamais. Après un Ctrl+C ou un crash, pas de Stop. Une session sans hook depuis 30 secondes et dont l'arbre de processus est calme est retirée, pour qu'un agent mort ne garde pas ton Mac éveillé.

Quand le dernier agent finit capot fermé, sans écran externe et sans personne devant, le Mac s'endort tout de suite. Un MacBook sur dock n'est pas touché : cette règle existe parce qu'un Mac s'est endormi en pleine frappe (#6).

Les hooks doivent aussi être rapides. Claude Code les lance avant et après chaque appel d'outil, et les attend. Sur un Mac chargé, ils prenaient 0,4 à 1,1 seconde chacun, parce qu'ils lançaient ps et pmset. Ils lisent maintenant les processus via libproc et l'état d'alimentation via IOKit, et prennent 20 à 60 ms.

#Tout le reste vient de ce qui a cassé

Garder le Mac éveillé a réglé le premier problème et révélé les suivants.

Le réseau lâche. Dans un train, un tour se termine sur une erreur réseau et l'agent attend que tu tapes « continue ». ASP garde le Mac éveillé jusqu'à 30 minutes, attend que l'API réponde 20 secondes d'affilée, puis tape le prompt dans ce terminal (iTerm2, Terminal ou tmux). Il abandonne après 3 essais, ne touche jamais aux erreurs de quota, de connexion ou de facturation, et attend si tu es en train de taper dans ce terminal.

Les agents ne savent pas s'arrêter. Certains vérifient quelque chose toutes les quelques minutes pendant des heures, et ton Mac reste debout toute la nuit pour rien. Tu peux donc fixer une échéance (asp force when-done --within 1h30) ou une heure de coucher (asp bedtime 2:00). Sur batterie, à 10 % ou moins, les agents ne gardent plus le Mac éveillé, et la veille revient aussi s'il surchauffe.

Une session dévore la machine. Ouvre assez de sessions et l'une d'elles finira par prendre toute ta RAM ou remplir ton disque. ASP te dit laquelle : arbre de processus au-delà de 8 Go, pression mémoire, swap, disque presque plein ou qui se vide vite. Il mesure phys_footprint, parce que le RSS rate la mémoire compressée, et il ne tue jamais rien. Si la session écoute sur Telegram, l'alerte arrive dans sa boîte et elle peut faire le ménage elle-même. asp monitor status montre la RAM de chaque session.

Tu t'absentes. asp telegram setup connecte ton propre bot, et /telegram dans une session la met à l'écoute. Un seul bot sert toutes les sessions : un message trouve la sienne par son topic, un préfixe nom:, une réponse ou des boutons. Les notes vocales sont transcrites sur ta machine (une note de 6 min 20 en 17 secondes sur mon Mac). Un groupe de projet peut même laisser un client parler à la session qui s'occupe de son projet, avec des règles strictes. Tes messages vont directement à l'API Telegram, sans serveur à moi au milieu, ce qui veut aussi dire que Telegram les voit : les discussions avec un bot ne sont pas chiffrées de bout en bout.

Tu rouvres les mêmes sessions tous les jours. asp workshop ouvre tes sessions nommées dans iTerm ou tmux, reprend chacune par son ID, répond aux questions de démarrage et tape tes premiers prompts.

Tu préfères parler. Maintiens Fn+Shift, parle, relâche. La dictée tourne en local avec Whisper ou Parakeet v3, et une liste de vocabulaire évite que « Cleemo » devienne « Climo ».

La barre de menus relie le tout : chaque session regroupée par projet et branche, qui travaille, qui a besoin de toi et pourquoi, ce qui tourne encore en arrière-plan avec un bouton Stop, et un clic pour sauter dans le bon terminal.

#Pourquoi l'ancien nom devait disparaître

Il avait déjà changé une fois : Claude Sleep Preventer est devenu Agents Sleep Preventer à l'arrivée de Codex.

Puis quelqu'un a ouvert une issue intitulée « Why does this project do speech-to-text? ». Question légitime. Ensuite est arrivé le mode serveur Linux : Telegram, surveillance RAM et disque, workshop, et aucune prévention de la veille, puisque cette machine ne dort jamais. Un Sleep Preventer qui n'empêche pas la veille, c'était la blague de trop.

Seul le nom affiché change. Le bundle ID, AgentsSleepPreventer.app, le DMG, le repo GitHub et le cask Homebrew gardent l'ancien nom exprès : macOS lie les permissions au bundle ID, et les installations existantes doivent continuer à trouver leurs mises à jour. Si tu l'as déjà installé, tu n'as rien à faire.

#Ce que tu lui confies

Un outil comme ça a de vrais accès, alors voici la liste :

• Une règle sudoers qui autorise quatre commandes pmset exactes, rien d'autre. Tu tapes ton mot de passe admin une fois, à l'installation.
• Des hooks fusionnés dans ta config Claude Code et Codex. Les tiens ne sont pas touchés.
• Les permissions Micro et Accessibilité, pour la dictée. L'audio est transcrit en local et ne quitte jamais ta machine.
• Des builds macOS signés et notarisés, avec des mises à jour Sparkle signées. Le ZIP Windows n'est pas signé pour l'instant.

Quelqu'un qui dit ne pas faire facilement confiance au logiciel des autres a audité le code avec Claude (#4). Verdict : aucun comportement malveillant, et une liste de problèmes bien utile. La règle sudoers autorisait n'importe quelle commande pmset. L'état des agents vivait dans le /tmp partagé, où un autre compte pouvait le falsifier. Le texte dicté finissait dans les logs. Tout ça a été corrigé dans les versions 5.0.2 et 5.0.4. Merci à @lbdremy.

Cet audit est antérieur à Telegram et à la surveillance RAM. Le code est public sous licence MIT, tu peux donc lancer le tien.

#Là où il peut encore se tromper

La détection d'activité reste une estimation. Un agent qui attend une longue réponse du modèle ne déclenche aucun hook et n'utilise presque pas de CPU : après 30 secondes, il peut sembler inactif. Et une session sans hook depuis 30 minutes est retirée même si son arbre de processus est occupé, sinon un serveur de dev oublié garderait ton portable éveillé indéfiniment. Capot ouvert, ça change rarement quelque chose. Capot fermé, le Mac peut s'endormir sur un agent bien vivant : ça m'est arrivé en octobre, en plein milieu d'un long run multi-agents.

Pour une nuit entière, ne compte donc pas sur la détection :

asp force awake   # avant de partir
asp force auto    # à ton retour

Les garde-fous gardent la priorité : surchauffe, batterie faible, heure de coucher.

Tout ne tourne pas partout non plus. macOS 14+ sur Apple Silicon a tout. Windows a la prévention de la veille, l'app dans la zone de notification et la dictée, et laisse le comportement du capot à tes réglages Windows. Linux, c'est le mode serveur : Telegram, surveillance RAM et disque, workshop dans tmux. Ces trois-là ne marchent qu'avec des sessions Claude Code. Codex a la prévention de la veille et le menu, plus la reprise automatique sur macOS.

#Essaie-le

Sur Mac (macOS 14+, Apple Silicon) :

brew install --cask charlontank/tap/agents-sleep-preventer

Ouvre Agent Session Pilot depuis Applications une fois pour terminer la configuration, puis relance tes agents.

Sur un serveur Linux :

curl -fsSL https://asp.charlon.dev/install.sh | sh
asp telegram setup

Sous Windows 10/11, récupère le ZIP dans la dernière release, extrais-le et lance asp.exe.

C'est gratuit, sous licence MIT et maintenu par une seule personne. Tout est sur asp.charlon.dev, et le code sur GitHub.

#En résumé

Ferme le capot et pars. Tes agents restent éveillés, tu sais ce qu'ils font, et ils sont à un message de toi.