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 GiB 可用内存。Linux 侧用 systemd-run --scope -p MemoryMax=；macOS 侧对照活动监视器的内存压力和交换空间。指标只有四个：Codex + 子进程峰值 RSS、是否开始猛写交换、任务是否做完、墙钟时间。

六组项目故意选「开发者真会丢给 Agent 的活」，而不是 Hello World：

1. P0 空会话：冷启动 codex，问一句仓库结构，不跑测试。
2. P1 小 Python CLI：约 180 个源文件，修一个解析 bug，跑 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 也比在一台已经开始换页的笔记本上盯着转圈诚实。