Codex CLI 實測：
8GB、16GB、32GB 記憶體分別能跑什麼專案

截至 2026 年 9 月 9 日，Codex 官方安裝說明仍寫：macOS 12+／Ubuntu 20.04+（Windows 走 WSL2），記憶體 4GB 最低、8GB 建議。CLI 本身已是 Rust 原生二進位檔，閒置時往往只有幾百 MB。它和 Claude Code、Cursor 一樣，貴的不是「Agent 行程」，而是 Agent 一動手就會喚醒的本機工具鏈。若你更在意另一套 Agent 的買機檔位，可對照我們寫過的 Claude Code 16GB／24GB／64GB 實測；若你要的是私有化 PR 審查服務，那是另一篇文章：OpenCode Review 4GB／8GB／16GB 選型。本文只回答一件事：Codex CLI 在 8／16／32GB 上分別能把哪類專案做完。

官方 4GB／8GB 只保證能啟動

把「建議 8GB」理解成「8GB 就能寫任何專案」是最常見的誤讀。官方表格解決的是：作業系統 + Node／執行時相依套件 + Codex 行程本身能不能活下來。它不涵蓋下面這些真實工作：

• 儲存庫裡有 node_modules、DerivedData、.next 或幾萬個原始檔，Agent 會按路徑讀、按工具搜；
• 你讓它「修這個失敗的 CI」，它會執行 npm test、pytest 或 xcodebuild；
• 你開了 Playwright／Chrome DevTools／XcodeBuild MCP，每個工作階段都可能再拉一棵 Node 行程樹；
• 本機同時開著瀏覽器、IDE、本機 dev server——這些都不算在「4GB 最低」裡。

推論發生在 OpenAI 一側，所以換更大的 GPU 幫不上忙。本機記憶體決定的是：工具鏈有沒有地方站著。這也是為什麼同一條官方說明，在腳本倉和 iOS 單體倉上會給出完全相反的體感。

記憶體帳單：CLI、索引、子行程、MCP

一次互動工作階段的常駐記憶體可以拆成四張帳單。分開看，你才知道該砍哪一項，而不是一上來加記憶體。

社群裡已經有夠刺耳的訊號：在約 1.2GB 的本機儲存庫上，有人觀察到 Codex 原生執行時匿名 RSS 漲到 18GB 乃至 29GB，直到 cgroup 把它殺掉（openai/codex#21233）。另一類問題是 MCP 生命週期：工作階段掛起或子 Agent 結束後，npx／Playwright／xcodebuildmcp 行程樹不退出，16GB 機器會被孤立行程拖進交換空間。所以「32GB 一定安全」也不成立——它只是給了你更長的反應時間。

這也是本文和「該買多大記憶體的電腦」類文章的差別：我們按專案工具鏈記帳，不按晶片代號推薦整機。

實測怎麼做：三檔上限、六組專案

我們用同一套 Codex CLI（ChatGPT 登入，預設編碼模型）跑六組固定任務，分別卡在 8／16／32 GB 可用記憶體。Linux 側用 systemd-run --scope -p MemoryMax=；macOS 側對照活動監視器的記憶體壓力和交換空間。指標只有四個：Codex + 子行程峰值 RSS、是否開始猛寫交換、任務是否做完、牆上時鐘時間。

六組專案刻意選「開發者真會丟給 Agent 的活」，而不是 Hello World：

1. P0 空工作階段：冷啟動 codex，問一句儲存庫結構，不跑測試。
2. P1 小 Python CLI：約 180 個原始檔，修一個解析錯誤，跑 pytest -q。
3. P2 中型 Next.js：約 800 個原始檔，加一條 API 路由，跑 npm test（不含 E2E 瀏覽器）。
4. P3 P2 + Docker Compose：Postgres + 應用容器，讓 Codex 改遷移並重啟堆疊。
5. P4 iOS App：中等 UIKit 工程，讓 Codex 改一處介面並執行 xcodebuild（不升模擬器全套）。
6. P5 P2 + Playwright MCP：打開瀏覽器 MCP，讓它對照頁面改元件。

數字是峰值區間，不是儀器標定。環境裡還留了作業系統和一個精簡終端；沒有同時開 40 個 Chrome 分頁。若你本機還掛著 Slack、Figma 和三個 dev server，請把下表每一檔再往上估一檔。

橫向結果：成功、卡住、被殺

讀這張表時請抓住兩件事。第一，P2 已經接近 8GB 的天花板——不是 Codex 吃了 8GB，而是 node 測試行程加上檔案讀取，把所剩無幾的空閒記憶體吃光。第二，P4／P5 失敗很少是「模型不會寫 Swift／不會點頁面」，而是編譯器和瀏覽器先把機器擠死，Agent 還沒走到最後一步。

8GB 能跑什麼專案

8GB 是官方「建議」檔，也是很多輕薄筆電、入門 VPS、舊款統一記憶體 Mac 的現實。它能完成的專案，特徵非常清楚：原始檔少、沒有容器、沒有 IDE 模擬器、測試是行程內的。

適合丟給 8GB 的專案

• 腳本、爬蟲、小工具、單檔重構；
• 文件站（Astro／VitePress／Docusaurus）的文案和設定修改；
• 小型 Flask／Express／FastAPI，測試用 pytest 或少量 Node 單元測試，不啟瀏覽器；
• 用 codex exec 做一次性補丁：讀幾個檔、改完就離開，不掛互動 TUI；
• Code review 註解、提交說明、把錯誤紀錄翻譯成補丁草稿。

8GB 上請直接放棄的專案

• 任何需要 Docker Desktop／Compose 的全端；
• Xcode、iOS 模擬器、Android 模擬器；
• Playwright、Cypress、Chrome DevTools MCP；
• pnpm／npm 的大型 monorepo 全量測試；
• 「一邊開 VS Code 和十幾個分頁，一邊讓 Codex 改倉」——系統會先開始換頁，你以為 Agent 變慢，其實是磁碟在替記憶體干活。

8GB 上最有效的用法不是「忍著跑大倉」，而是把大倉拆成小任務：只打開子目錄、關掉 MCP、用 codex exec 做完就走。互動式長工作階段是 8GB 的天敵——工作階段越長，內部狀態和子行程越容易留下。

16GB 能跑什麼專案

16GB 是我們建議的日常 Web 預設檔。P2 這類「中型前端／全端 + 單元測試」在這一檔終於不用和交換空間搶時間。Nuvcloud 雲端 Mac mini 的入門規格也是 16GB 統一記憶體，和這一檔對齊：本機輕薄筆電不夠時，把 Codex 工作階段連同工具鏈一起挪到獨享節點，比在 8GB 筆電上硬扛更省事。

16GB 舒服的專案

• 中型 Next.js／Nuxt／Rails／Django，單元測試 + 本機 dev server；
• 一個資料庫容器，或一個很瘦的 docker-compose（不要再疊 Redis + Elasticsearch + 瀏覽器）；
• VS Code／Zed + 終端 Codex，同時留 2–3GB 給系統；
• 中等 Python 資料腳本（pandas 中等表，不上完整本機大型語言模型）；
• 短時間打開一個 MCP（例如 Git 或文件檢索），用完立刻關。

16GB 能做、但要守規矩的專案

P3 在 16GB 上「能做完」，前提是你接受記憶體壓力發黃、並且不要並行第二套容器。iOS 小改動如果只跑 xcodebuild 的單個 target，有時也能擠過去，但模擬器一開就回到「交換 + 卡死」區間。Playwright MCP 的短工作階段（十幾分鐘）可以，一旦你 Ctrl+Z 掛起工作階段或連續 spawn_agent，孤立 Node 行程會把 16GB 吃穿——社群在 16GB + 8GB zram 的機器上已經重現過整機不可用。

一句話：16GB 適合「一個主專案 + 一套測試」；不適合「主專案 + 容器全套 + 瀏覽器 Agent + IDE 索引」。

32GB 才該上的專案

32GB 不是炫配置，是下面這些專案的入場券。它們的共通點是：Codex 只佔帳單的一小截，編譯器和執行環境才是大頭。

• 單體倉／多套件儲存庫：一次 npm test 或 turbo run test 會拉起一排 Node worker；
• iOS／macOS 工程：xcodebuild、DerivedData、程式索引，峰值輕鬆到十幾 GB；要對照介面再開模擬器，請按 32GB 規劃；
• Codex + Docker 多服務：應用、資料庫、訊息佇列同時在，再讓 Agent 改遷移、重啟堆疊；
• 瀏覽器 MCP／端對端：Playwright 或 Chrome DevTools 會再複製一棵行程樹；短工作階段 32GB 夠用，長工作階段仍然要手動收屍；
• 多工作階段並行：兩個 Codex 看兩個儲存庫，或一個互動工作階段加一個 codex exec 批次。

32GB 也擋不住已知的無上限成長。若你的儲存庫本身就有 1GB 級工作區，請給 Codex 加記憶體上限，寧可任務失敗，也不要讓桌面一起凍住。Linux 上可以這樣包一層：

# 32GB 機器上給 Codex 留 20G，其餘給系統／IDE／容器
systemd-run --user --scope \
  --same-dir \
  --unit="codex-$(date +%H%M%S)" \
  -p MemoryMax=20G \
  -p MemorySwapMax=2G \
  -p CPUQuota=300% \
  codex

macOS 沒有同樣好用的使用者空間 cgroup，更現實的做法是：重活放到獨享的雲端 Mac，本機只留編輯器和瀏覽。Nuvcloud 目前對外的裸金屬檔是 16GB 與 24GB——24GB 已經涵蓋大多數 P3，P4 若要同時開模擬器，優先把 Xcode 和 Codex 放到那台常開的遠端機器上，而不是逼 16GB 筆電兩頭兼顧。把 Agent 節點單獨計費，也方便對照 GitHub Actions macOS Runner 的託管與自建成本：CI 用一次性 runner，互動式 Codex 用按日出租的 Mac mini，兩本帳不要混在一台滿載的筆電上。

按儲存庫與工具鏈選檔

不要先問「我該買 16 還是 32」，先問儲存庫會喚醒什麼。下面這張表按決策順序排，從上到下遇到第一條就停。

還有一個常被忽略的變數：磁碟和檔案描述子。MCP 洩漏時，macOS 預設軟性上限 256 個檔案描述子就可能先報 Too many open files，看起來像「Codex 壞了」，其實是管線和孤立行程把額度吃光。記憶體夠不夠之前，先看 ulimit -n 和 ps 裡有多少 npx／mcp。

小記憶體機器上的保命設定

如果你暫時只能在 8GB 或吃緊的 16GB 上工作，先改行為，再談升級。下面這份清單是按「效益／痛苦」排的。

1. 預設零 MCP。 需要瀏覽器或 Xcode 工具時再開，用完從 ~/.codex/config.toml 拿掉。不要把 xcodebuildmcp、Playwright 寫進全域預設。
2. 互動工作階段短、批次用 codex exec。 一次性補丁不必掛 TUI；批次處理少佔一層介面狀態。
3. 不要用 Ctrl+Z 掛起 Codex。 掛起後 MCP 子行程常常繼續活著。離開，或在 tmux 裡 detach。
4. 縮小工作目錄。 在子套件裡啟動，而不是在 4 萬檔的 monorepo 根目錄啟動；把 dist、coverage、.next 排除出讀取範圍。
5. 限制工具輸出。 社群實務裡會給 tool_output_token_limit 設上限，避免一次讀完整紀錄就把上下文和本機緩衝一起撐爆。
6. 看行程，不要只看「好慢」。 ps aux | egrep 'codex|npx|mcp|node' 裡如果出現十幾組重複的 MCP 樹，先殺孤立行程再繼續。

ps aux | egrep 'codex|npx|playwright|mcp-server|xcodebuildmcp' | grep -v egrep
# 工作階段結束後如果還在，先收屍再開下一輪
# macOS 也可在活動監視器裡按「記憶體」排序，盯住 node 和 Codex

這些步驟不能把 P4 變成 8GB 友善專案，但能讓 P1／P2 從「能開機」變成「能做完」。升級記憶體解決的是峰值；改設定解決的是洩漏和並行。

什麼時候把 Codex 丟到雲端 Mac

滿足任意兩條，就該把 Codex 和重工具鏈從筆電上拆走：

• 本機只有 8GB 或 16GB，但任務已經是 P3／P4／P5；
• 你需要在通勤、Windows 主機或共用電腦上繼續同一條工作階段；
• Xcode 版本要和本機日常開發隔離（SDK 週、beta 週尤其明顯）；
• 團隊有人把 MCP 配成全域預設，共用機器會在下午被孤立行程打滿。

雲端 Mac mini 的價值不是「更貴的 Codex」，而是獨享統一記憶體、原生 Unix 工具鏈、可以按日丟掉的髒環境。本機 8GB 筆電繼續寫郵件和看文件；16GB 或 24GB 的遠端節點專門跑 Codex、測試和 Xcode。Apple Silicon 待機功耗低，適合掛隔夜任務；SSH／VNC 也比在一台已經開始換頁的筆電上盯著轉圈誠實。