开发者Simon Willison用磁盘分析工具OmniDiskSweeper清理硬盘时，在~/.cache文件夹里挖出了一个不寻常的东西：OpenAI Codex桌面应用（今年已改名并入ChatGPT桌面应用）留下的一个名为codex-primary-runtime的目录，占用1.7GB。里面不是常见的缓存垃圾，而是一整套完整的Python和Node.js运行环境，外加LibreOffice、Poppler、git的原生二进制文件。
这不是意外堆积，而是有意为之的产品设计。Codex把一整个办公软件生态塞进了本地缓存，为的是让它能离线、自主地处理Office文档——但这套“重装上阵”的架构，换来的实际体验却谈不上领先。
这1.7GB到底装了什么
拆开来看，dependencies目录里最大的两块是Node.js和Python的完整安装包，其余是一批原生工具：LibreOffice的无头版（headless，不带界面、专供脚本调用）、PDF处理库Poppler、版本控制工具git，还有两个小体积的图像库libheif和jxrlib。
对应的版本线也基本对齐了各自项目今年8月的最新发布节奏：LibreOffice对应26.8.0分支（8月26日发布），Poppler是26.08.0稳定版（8月2日），Python是3.14.7维护版（8月5日），Node.js是26.8.1 Current版（8月26日）。换句话说，OpenAI在打包这套工具链时，用的都是当时能拿到的最新版本，不是随手塞了个旧包了事。
Documents技能：把文档变成图片给模型看
这套工具链服务的是一个具体功能，Codex内部称之为“Documents”技能。它的处理逻辑并不复杂：先用LibreOffice的无头模式把DOCX文件转成PDF，再用Poppler把PDF栅格化成图片，最后把图片交给模型去“看”。
这解决了一个大模型的老问题——它们读不懂DOCX这种二进制格式的排版结构，但能理解图片里的文字和布局。与其教模型解析Office文件格式，不如让本地工具先把文档“拍”成截图。这是一种确定性强、离线可用的思路：不依赖网络API，不依赖用户本地是否装了Office或LibreOffice，随应用分发、随时能跑。
- 风险.这条链路完全靠OpenAI自己维护，一旦某个环节出bug，责任也全在自己身上。
这个风险不是假设。Windows平台上已经出现了一个已知问题：临时用户配置路径的写法用了错误的URI格式（file://C:\...而非规范的file:///C:/...），导致渲染直接失败。这个issue在GitHub上截至发现时仍处于open状态，没有被关闭。
打包得越重，体验反而越轻
有意思的对照在于，同样面对“AI要处理Office文档”这个需求，Claude Code和Gemini CLI选的是完全相反的路子——不打包，走MCP协议按需连接本地已装的LibreOffice或专用MCP服务器，社区围绕这条路径已经长出了像claude-libreoffice、Nelson MCP这样相对成熟的工具。
打包最重的那个，体验排名反而垫底。
按社区评测，三家在LibreOffice实际文档编辑体验上的排序里，Codex被认为“技术上可行，但配置摩擦最多、社区工具生态最不成熟”，排在Claude Code和Gemini CLI之后。截至目前，三家都还没有做出类似Microsoft 365连接器级别的原生LibreOffice集成，谁也没有真正解决问题，只是Codex走的这条路看起来投入最大、产出却最不划算。
对普通用户来说，这1.7GB本身不算致命，但它说明了一件事：应用体积和实际能力并不总是同向变化。真正需要用AI批量处理Office文档、拼PDF、做文档自动化的用户，选型时该看的是谁的社区扩展和实际编辑成功率更高，不是谁的本地缓存塞得更满。
还有一层容易被忽略的问题：LibreOffice和Poppler都是开源项目，被闭源商业应用无声嵌入使用，本身不违反LGPL许可，但既没有公开的版本维护说明，也没有看到向上游反馈bug或做贡献的迹象。这种“拿来即用、出了问题自己憋着修”的模式，长期来看对开源社区并不友好。
这个bug什么时候修、OpenAI是否会公开这套打包策略的官方说明、后续版本是不是会转向更轻量的按需调用架构，都还没有答案。值得盯的不是这1.7GB本身，而是OpenAI愿不愿意为这条自建的文档处理链路持续买单。