OpenAI 的 ChatGPT/Codex 桌面应用在 codex-primary-runtime 文件夹内捆绑了完整的 LibreOffice 副本、Python 安装包、Node.js 安装包以及 Poppler 和 git，占用数 GB 空间。此前 Anthropic 的 Claude 桌面应用已捆绑 10GB 虚拟机。

这种打包方式直接把大量第三方完整软件塞进 AI 应用安装包里。开发者不再依赖用户已有的系统环境，而是把运行时代码和依赖全部打包，确保 AI 代理能在本地可靠执行复杂任务。两个案例都指向同一个趋势：AI 桌面应用正把本地执行能力放在首位，哪怕付出体积和复杂度的代价。

ChatGPT 与 Claude 桌面应用在运行时捆绑上的共同模式

OpenAI 的 ChatGPT/Codex 应用和 Anthropic 的 Claude 桌面应用都选择了大规模本地运行时嵌入策略。ChatGPT/Codex 把完整工具链放在 codex-primary-runtime 文件夹内，而 Claude 则直接打包了 10GB 的虚拟机。两者都没有采用轻量调用系统已安装软件的做法，而是把整个环境复制一份。

这种模式正在成为 AI 桌面应用的默认做法。原因在于 AI 代理需要可靠地调用外部工具来完成用户指令，比如编辑文档、运行代码或处理 PDF。如果依赖用户机器上已安装的 LibreOffice 或 Python，版本不匹配、路径错误或缺失组件都会导致任务失败。打包完整副本能让开发者在自己控制的环境中测试和优化代理行为，避免跨平台兼容性问题。

目前看来，这一做法并非个别选择，而是行业内处理本地执行不确定性的主流方案。两个独立团队在不同时间得出相似结论，说明在当前技术条件下，全量打包运行时是确保 AI 工具实际可用性的最直接路径。信号中提到的两个案例都发生在桌面应用场景，进一步印证了这一模式在追求离线或半离线能力时的普遍性。

codex-primary-runtime 文件夹里到底塞了哪些完整工具

根据公开信息，codex-primary-runtime 文件夹包含以下完整组件：完整的 LibreOffice 副本，这是一个功能齐全的开源办公套件，涵盖文字处理、电子表格、演示文稿和绘图工具；完整的 Python 安装包，提供解释器和标准库；完整的 Node.js 安装包，包含 JavaScript 运行时和 npm 生态；此外还有 Poppler，用于 PDF 渲染和转换；以及 git，用于版本控制。

这些不是精简版或 API 封装，而是可独立运行的完整安装。LibreOffice 能直接打开和编辑 .docx、.xlsx 等格式文件，Python 和 Node.js 允许 AI 代理编写并执行脚本，Poppler 处理 PDF 提取文本或转换格式，git 则支持代码仓库操作。

把这些工具全部打包进去，意味着 codex-primary-runtime 文件夹体积达到数 GB。开发者没有选择只提取必要二进制文件或动态链接系统库，而是直接复制整个发行版。这种选择简化了打包流程，但也直接导致了应用体积的膨胀。信号显示，这些组件共同构成了 AI 代理在本地操作文档、运行代码和处理文件的完整能力基础。

完整办公套件对 AI 代理本地执行能力的支撑逻辑

AI 应用需要把整个 LibreOffice 和编程环境一起打包，主要为了让代理能在本地完成真实世界任务，而不只是生成文本。LibreOffice 提供成熟的文档处理能力，AI 可以直接调用其命令行接口或 COM 接口来创建、修改和导出办公文件。Python 和 Node.js 则让代理能运行用户提供的脚本或生成新脚本并立即执行。

Poppler 负责 PDF 解析，这是办公场景中常见的文件格式。git 的加入表明 AI 可能被用于代码相关任务，比如在本地仓库中提交变更或审查差异。这些组件共同形成了一个自包含的沙盒环境，AI 代理可以在其中安全地执行文件操作、代码运行和格式转换，而无需用户额外配置。

从技术选型看，这种做法回避了与系统已安装软件的冲突问题。不同用户机器上 LibreOffice 版本差异巨大，直接调用可能引发兼容性崩溃。打包完整副本让 OpenAI 能在统一环境中验证代理行为，确保指令如“帮我把这份报告转成 PDF 并加页眉”能可靠完成。这种全量打包反映出当前 AI 代理开发中对确定性和可控性的优先考虑，尽管代价是更大的安装包。

数 GB 额外体积对普通用户安装与存储的真实负担

codex-primary-runtime 文件夹占用数 GB 空间，这对用户下载和安装体验构成直接压力。许多用户，尤其是笔记本电脑或存储空间有限的设备用户，需要花费更长时间下载应用，安装后还会占用宝贵磁盘空间。

以数 GB 计算，如果用户同时安装 ChatGPT/Codex 和 Claude 桌面应用，仅运行时部分就可能消耗超过 15GB 存储。更新时如果每次都重新下载完整包，流量和时间成本会进一步增加。普通用户可能不清楚为什么一个聊天工具需要这么大的体积，容易产生困惑或直接放弃安装。

这一负担在企业或教育场景中同样明显。批量部署时，数 GB 的额外体积会增加网络负载和设备管理难度。虽然对拥有高速网络和大容量 SSD 的开发者来说影响有限，但对大量普通用户而言，这已成为真实障碍。信号中提到的两个案例都暴露了同一问题：追求本地执行能力的 AI 应用正在把体积问题推给终端用户。

直接嵌入 LibreOffice 等开源项目对生态的反向作用

AI 应用大量使用 LibreOffice、Python、Node.js 等开源项目，却没有深度参与上游开发，这对开源生态可能产生负面影响。LibreOffice 项目需要社区贡献来修复 bug、适配新平台和改进性能。当商业 AI 公司只是打包二进制而不提交补丁时，相当于免费使用了社区多年积累的成果，却没有反哺。

类似情况也出现在 Python 和 Node.js 生态。如果大量 AI 应用都打包自己的完整副本，而不是调用系统版本，会导致重复安装和资源浪费。同时，上游项目难以从这些 AI 应用的使用场景中获得反馈，比如特定办公自动化需求的优化建议。

长期来看，这种只索取不贡献的模式可能削弱开源项目的活力。LibreOffice 开发者可能不知道自己的软件正被用于支持数百万 AI 代理的任务执行，也就无法针对这些使用模式进行针对性改进。信号显示的打包行为凸显了 AI 公司与开源社区之间潜在的协作缺失。

这种全量运行时策略可能带来的安全与维护隐患

捆绑完整第三方软件在更新、漏洞管理和权限控制上带来明显问题。LibreOffice、Python 或 Poppler 一旦发现安全漏洞，AI 应用就需要尽快更新整个打包副本，否则用户设备上就存在已知风险。但由于这些组件被嵌入应用内部，普通用户难以单独更新它们，只能等待官方新版本发布。

维护负担也随之增加。OpenAI 需要同时跟踪多个上游项目的发布节奏，确保打包版本兼容代理代码。这增加了开发和测试成本，一旦某个组件更新引入不兼容变化，整个 codex-primary-runtime 都可能需要重新构建。

权限管理同样复杂。打包的 git 和 Python 可能需要访问用户文件系统，如果 AI 代理被诱导执行恶意指令，这些工具的权限就可能被滥用。虚拟机方案如 Claude 所用的 10GB 环境虽然隔离性更好，但本身也可能成为攻击面。信号中的案例表明，目前这些安全和维护隐患仍未得到彻底解决，全量运行时策略在带来便利的同时，也把复杂性转移给了用户和开发者。

参考来源