codex exec 生成一張 1.7 MB 的圖，~/.codex 裡存了約 8 MB

codex exec 是 Codex 的非互動模式：給一段 prompt，它做完就結束。-o 指定一個檔案，寫出最後一則回覆。我一直把它當成一般的命令列工具，以為除了那個檔案，別的不留。

但 10 月 15 日中午這台 Mac 的磁碟只剩 2.5 GB 左右（怎麼看剩多少，見 df 的 Capacity 那篇），我量了 ~/.codex：中午 12:42 時，sessions 目錄有 1,877 個檔案、6,144 MB，留存最早的一個是 5 月 3 日。這篇要談的是 codex exec 每跑一次留下什麼，以及為什麼生成圖片的那幾次特別大。依序是：我怎麼量、10 月的 4.6 GB 裡是什麼、一張圖存在哪幾個地方、--ephemeral 測到少寫了什麼，最後是還沒測到的部分。

量法：程式只輸出結構和長度

session 檔是 JSONL（一行一筆 JSON），檔名像 rollout-2026-10-15T12-38-28-….jsonl，依日期放在 sessions/2026/10/15/ 這樣的目錄裡。裡面有 prompt 和工具輸出，所以我用一支 Python 腳本讀取、解析，只讓它輸出三種東西：第一行 session_meta 裡的 originator（codex_exec 就是 codex exec 產生的），依每行的 type 加總的長度，以及圖片欄位的 SHA-1 比對結果。我沒有人工去讀，也沒有印出任何對話或圖片內容。

下面的 MB 是 10⁶ 位元組。檔案大小是位元組；欄位長度是字元數，base64 都是 ASCII，字元數等於位元組數，其他含中文的欄位則會少算一些，遇到時另外標出。除非另外寫時間，統計都是 10 月 15 日 12:15 左右的快照。

10 月的 4.6 GB 裡是什麼

10 月 1 日到 15 日 12:15，sessions/2026/10 有 1,326 個檔案，其中 1,162 個是 codex_exec，合計 4,606 MB。單檔中位數 4.43 MB、第 90 百分位 5.61 MB、最大 33.5 MB。量最多的一天是 10 月 1 日：342 個 exec session、1,801 MB。

依記錄類型拆開，大頭是兩種：

• event_msg 裡 item_completed 的 Extension 項目，kind 是 image_gen.generation，result 欄位是生成圖的 base64：865 張、1,935 MB。
• response_item 裡 custom_tool_call_output 的 input_image，也就是工具回給模型看的圖：1,077 個、2,021 MB。

兩者加起來 3,956 MB，約占 1,162 個檔案總位元組數的 86%。執行指令的紀錄（CommandExecution 項目所在的那些行）總共約 297 MB，同一份輸出在 stdout 和 aggregated_output 兩個欄位各存一次（6,588 筆都相同），但跟圖片比是小數。1,162 個 exec session 裡，有 845 個生成過圖片，這 845 個檔案合計 4,128 MB。換句話說，這個月的 session 檔，位元組大部分是那批工作生成的圖片。

一張圖存在哪幾個地方

那 1,077 個 input_image 是什麼圖？把每個的 base64 算雜湊，和同一個 session 裡生成圖的 base64 比，859 個逐位元組相同，對應 850 張生成圖：圖生成之後，原樣再交給模型一次，兩份都寫進 session 檔。

session 檔之外還有兩份。生成項目的 savedPath 都指向 ~/.codex/generated_images/ 下的 PNG（依修改時間算，10 月有 899 個、1,524 MB）。所有留存的 session 裡共有 899 個 savedPath（10 月目錄 873 個，9 月 26 個），都還存在，把 base64 解碼之後與 PNG 全部相同。另一份在 ~/.codex/thread_history_1.sqlite：這個當時 2.69 GB 的 SQLite 資料庫有一張 thread_items 表，其中 899 個 imageGeneration 項目的 JSON 合計約 2,034 MB，解碼後也都和對應的 PNG 相同。

所以是幾份？把 865 張生成圖逐張數：842 張剛好四份（PNG、session 檔裡兩份、資料庫一份），15 張沒有回給模型、是三份，8 張回給模型兩次以上、是五份或更多。只看剛好四份的那 842 張，PNG 平均 1.68 MB（標題的 1.7 MB），四份合計平均 8.40 MB，是 PNG 本身的五倍左右。base64 大約比原檔大三分之一，存三次就是這個結果。這是檔案和欄位裡的內容量；每生成一張圖，磁碟實際增加多少，我沒有單獨量過。

這不是過去式。12:35 到 12:42 之間，這台機器上又有 5 個新的 exec session 寫進 sessions/2026/10/15/，每個 4.2 到 4.8 MB。

--ephemeral 測到少寫了什麼

codex exec --help（codex-cli 0.159.2）對這個旗標只有一行：Run without persisting session files to disk。我在一個新建、不在 git 裡的測試目錄跑了兩次只回一個字的 exec：

codex exec --ephemeral --skip-git-repo-check -s read-only "Reply with exactly: ok" < /dev/null

第一次前後比對：sessions 底下的檔案數 1,872 → 1,872；history.jsonl、session_index.jsonl 大小不變；state_5.sqlite 的 threads 表裡沒有 cwd 是那個目錄的列；logs_2.sqlite 的 logs 表在那 7 秒內沒有新列。第二次先 touch marker，跑完用 find ~/.codex -type f -newer marker 找比它新的檔案，sessions 底下是 0 個。

find 也列出了幾個被改過的 SQLite 檔和快取檔。那時我用 ps 數到 37 行含 codex 的行程，別的工作也在跑，我沒辦法把這些修改歸給這兩次測試。所以只能說：在我查的這幾處，這兩次 --ephemeral 沒有留下紀錄。代價也是同一件事：沒有 session 檔，這兩次就沒有東西可以 codex exec resume。

沒測到的，以及我現在怎麼做

已知的是上面這些數字。我沒測的有兩件：加了 --ephemeral 之後生成圖片，generated_images 底下還會不會寫 PNG；以及手動刪掉舊的 session 檔之後，Codex 的 app 和 thread_history_1.sqlite 會怎麼反應。前者要另外跑一次生成測試，後者會動到別的工作正在用的資料，所以都先留著。

現在的做法是：一次性的 codex exec（查核、驗收、讀圖檢查）一律加 --ephemeral，因為這類工作我不會回頭 resume，要的只是 -o 那份輸出。要生成圖片的工作，生成前後各用 du -sk 量一次 ~/.codex/sessions、~/.codex/generated_images 和 thread_history_1.sqlite（連同 -wal 檔），看增加的量級是不是每張幾 MB；同時有別的工作在跑時，這個數字只能當參考。舊檔我還沒刪。

如果只記得一件事

codex exec 預設會把執行過程寫進 ~/.codex/sessions；在這台 Mac 上，大多數生成圖在 session 檔裡存兩次、在 thread_history 資料庫再存一次，加上 PNG 共四份。10 月 exec session 的位元組有 86% 是 base64 圖片。不打算 resume 的執行加 --ephemeral；要生成圖片時，我先用每張約 8 MB 估算（這是內容量，實際磁碟增量我沒單獨量過）。