2026 年 OpenAI Codex CLI 在 Mac 怎么安全部署？

截至 2026 年 8 月 2 日，官方文档列出了 3 种常见沙箱模式：read-only、workspace-write 和 danger-full-access。这直接决定了 Codex CLI 能否修改文件、运行命令以及访问网络。(learn.chatgpt.com)

症状：为解决一次测试报错，你给 Codex CLI 开了过大的权限，随后发现它可以看到不该看的配置，或者改动了整个项目。
最快解法：先用最小仓库、受限凭据和可回滚任务完成验收。低风险短任务留在现有 Mac；敏感代码、无人值守或长任务，迁移到独立账号、备用 Mac 或隔离的云端 Mac。

这篇文章适合三类人：

• 独立开发者：想在个人 Mac 上运行 Codex CLI，但担心误改文件或读取敏感配置。
• 研发团队：准备把编码 Agent 接入真实仓库，需要统一权限和验收标准。
• 环境管理员：需要交付可重置、可审计、适合长任务的 macOS 环境。

最后更新于 2026 年 8 月 2 日。安装方式、身份验证、沙箱和审批行为已对照 OpenAI Codex CLI 文档、配置参考、安全说明及官方代码仓库复核。长任务稳定性和恢复效果不作未经实测的保证。

部署前：先选任务边界，再选 Mac

Codex CLI 会在本机终端中检查文件、修改代码、运行命令，也可以通过 codex exec 参与自动化流程。官方定位并不是“只读代码问答工具”，而是能在本地仓库中执行工作的编码 Agent。(developers.openai.com)

所以部署前先回答三个问题：

1. 代码敏感度如何？
   示例代码、公开项目和低风险个人项目，可以先在现有 Mac 试用。涉及商业源码、生产配置、证书、客户数据或私有模型提示词，不要直接使用主力账号和主力工作区。

2. 任务是否需要长时间运行？
   交互式重构、单元测试修复和代码解释适合主力 Mac。无人值守构建、批量迁移、持续测试和夜间任务，需要稳定在线的备用 Mac 或云端 Mac。

3. 任务能否回滚？
   首个真实任务必须是小范围、可提交、可丢弃的改动。不要把数据库迁移、生产发布或全仓库格式化作为第一次验收任务。

初始环境对比

不要把整个用户目录作为默认工作区。项目目录应当只包含本次任务需要的代码和测试数据，~/.ssh、环境文件、证书目录、个人配置和其他仓库都应置于边界之外。

如果你还没有备用设备，可以先查看 MacHTML 的帮助页面，确认远程连接、环境交付和重置流程，再决定是否用云端 Mac 做隔离试点。

首次运行：安装来源与身份路径

安装只采用官方文档或官方代码仓库提供的方式。当前官方快速安装方式是：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

官方仓库同时列出 npm、Homebrew 和平台专用发布包等路径。首次部署不要混用多种安装方式，否则后续排查版本来源、二进制路径和自动更新行为会变得困难。(github.com)

完成安装后，立即记录：

which codex
codex --version
codex login status

版本号以你现场输出为准，不要照抄网络文章中的版本。官方文档和发布记录会持续变化，安装记录中至少保存安装命令、来源、版本、系统版本和当前用户。

Codex CLI 当前支持两类本地身份路径：

官方说明中，ChatGPT 登录与 API 密钥会对应不同的工作区权限和数据处理策略；API 密钥适合程序化工作流，但不要把 Codex 执行暴露在不可信或公开环境中。(developers.openai.com)

如果必须使用 API 密钥，官方示例是通过标准输入传递：

printenv OPENAI_API_KEY | codex login --with-api-key

不要把密钥直接写进 Shell 历史、仓库文件或任务提示词。完成登录后，再用 codex login status 确认当前身份，用 codex logout 验证撤销路径。登录凭据可能保存在 ~/.codex/auth.json 或系统凭据存储中，个人 Mac 上尤其要注意这一点。(developers.openai.com)

第一小时：沙箱与最小权限基线

官方对本地 Codex 的权限控制分成两层：沙箱决定技术边界，审批策略决定何时暂停并询问你。它们不是同一个开关。即使某条命令需要审批，也不代表批准后就应该获得整个文件系统的访问权。(learn.chatgpt.com)

建议第一次启动使用以下基线：

codex --sandbox read-only --ask-for-approval on-request

先完成代码浏览、项目结构分析和测试命令识别，再切换到：

codex --sandbox workspace-write --ask-for-approval on-request

三种模式的实际含义如下：

• read-only：可以检查文件，但修改文件、运行命令或访问网络时需要审批。
• workspace-write：可以在当前工作区内编辑文件并运行常规本地命令；越出工作区或访问网络时需要审批。
• danger-full-access：取消文件系统和网络边界。官方明确将其视为高风险模式，不应作为解决权限报错的默认捷径。(learn.chatgpt.com)

审批策略也要单独理解：

• untrusted：对不在可信集合中的命令询问。
• on-request：在沙箱内自动运行，越界时询问。
• never：不再停下来请求审批。

在 macOS 上，Codex 使用系统 Seatbelt 机制执行沙箱策略。官方文档还提供了 codex sandbox macos 和 --log-denials 等诊断方式，可用来确认某条命令究竟被哪条边界拦截。(learn.chatgpt.com)

经验：权限报错首先要查当前目录、可写根目录、网络策略和命令本身。直接切到 danger-full-access，只是把错误从“命令无法执行”变成“命令可以执行但边界消失”。

测试仓库：用证据而不是感觉通过首轮

建立一个不含密钥的测试仓库。里面只放一个简单项目、几份测试文件和一个明确的修改目标。首轮验证至少覆盖以下动作：

1. 让 Codex 读取项目结构，确认它没有主动访问上级目录。
2. 让它修改一个指定文件，检查差异是否只出现在授权目录。
3. 让它运行一个本地测试命令，记录是否需要审批。
4. 让它尝试访问网络，确认网络请求是否被阻止或提示。
5. 让它读取一个工作区外的临时文件，确认边界不会静默扩大。
6. 删除测试改动，重新执行同一任务，验证回滚路径。

通过标准不是“任务成功完成”，而是：

• 读取范围符合预期；
• 写入范围没有越界；
• 每次越界都有可见审批；
• 测试命令不会带入个人密钥；
• Git 差异可以被人工复查；
• 删除工作区后可以重新开始。

如果团队需要统一默认配置，可以把 sandbox_mode、approval_policy、approvals_reviewer 和可写根目录写入 config.toml。官方配置参考支持通过可写根目录扩大指定目录，而不是取消整个沙箱。(learn.chatgpt.com)

首个真实任务：隔离仓库、凭据与网络

首个真实任务选“小而可回滚”的改动。例如，为一个模块补测试、修复一个明确报错，或生成一份不涉及生产数据的迁移草案。

不要直接给它以下内容：

• 生产环境变量；
• 长期有效的云服务密钥；
• 个人 SSH 私钥；
• 浏览器配置目录；
• 包含客户数据的数据库导出；
• 多个无关仓库的父目录。

更稳妥的做法是创建任务专用凭据。权限只覆盖测试环境，设置过期时间或撤销步骤。任务完成后立即检查调用记录，必要时撤销凭据。

网络依赖也要拆开记录。包安装、下载外部工具、访问 API 和调用 MCP 服务不是同一类风险。每次批准都写清楚“为什么需要、访问什么、批准到什么时候”，不要把一次性批准理解为以后所有任务都可以联网。

首个真实任务记录表

如果你准备在 Mac 上长期运行多个编码 Agent，建议把安装来源、配置文件位置、审批规则和撤销步骤整理成团队模板，避免每位开发者自行决定权限范围。你也可以参考 MacHTML 的环境管理入口，把这套记录方式扩展到多人试点和远程设备交付。

长任务：主力 Mac 与云端 Mac 的取舍

长任务最容易暴露部署设计的问题。终端断开、系统休眠、网络波动、自动更新、用户注销和设备重启，都可能让“看起来能运行”的环境失去连续性。

你需要主动模拟至少四种中断：

• 关闭终端窗口；
• 让 Mac 进入休眠后唤醒；
• 暂时断开网络；
• 终止一个正在运行的命令。

每次都检查三件事：会话是否还能识别，工作树是否保持一致，执行记录和 Git 差异是否可以复查。官方文档说明 codex exec 可用于非交互式任务，但这不等于你的 Mac 已经具备可靠的无人值守能力。(github.com)

主力 Mac 的优点：

• 交互反馈快；
• 本地开发工具齐全；
• 适合边看边改的短任务。

主力 Mac 的缺点：

• 合盖、重启或日常使用会打断任务；
• 个人凭据和其他项目容易混入；
• 出现权限问题时，临时放权的诱惑更大。

云端 Mac 的优点：

• 可以为单一试点建立独立工作区；
• 更适合持续在线和远程访问；
• 任务结束后可重置环境，减少残留配置。

云端 Mac 的缺点：

• 需要额外管理 SSH、VNC、网络白名单和登录凭据；
• 代码同步与数据传输本身也要审计；
• 如果交付流程不标准，远程环境可能只是另一台“没人管的主力机”。

因此，短任务选主力 Mac，长任务选备用或云端 Mac。真正的判断条件不是 CPU 性能，而是你能否控制设备在线状态、权限边界、凭据生命周期和回滚路径。需要临时隔离环境时，可进一步核对云端 Mac 的交付方式和重置流程，不要只比较租用时长。

第一周验收：五类证据决定是否上线

试点运行一周后，不要只问“Codex CLI 是否好用”。用以下五类证据决定是否继续：

• [ ] 权限越界测试已完成，工作区外读取和写入行为有记录。
• [ ] 错误写入可以通过 Git、补丁或干净副本回滚。
• [ ] 任务专用凭据已完成撤销，并确认旧凭据不能继续使用。
• [ ] 终端断开、休眠、网络波动和失败任务的处理方式已验证。
• [ ] 每次结果都经过人工复查，没有把 Agent 输出直接合入生产分支。
• [ ] 安装来源、版本、配置文件、审批规则和环境负责人已登记。
• [ ] 长任务的停止条件已经写明，例如超时、连续失败或修改文件数异常。
• [ ] 云端 Mac 或备用 Mac 的重置、交付和回收步骤可以重复执行。

低风险个人项目，可以在现有 Mac 上保留 workspace-write 与 on-request 的组合。敏感仓库、并行项目和持续任务，则应使用独立账号、独立工作树，或可重置的云端 Mac。高权限模式只适合已经完成隔离的环境，不能成为日常默认配置。

如果你正在比较本地部署与远程环境，先把验收记录整理成团队可复用的环境模板。完成权限、回滚和中断恢复测试后，再决定是否扩大使用范围。

对大多数人来说，当前方案的真实问题不是“Mac 性能不够”，而是主力设备同时承担个人文件、多个仓库、浏览器登录状态和长任务执行，导致权限边界模糊、任务容易中断、出错后难以恢复。直接在主力 Mac 上长期运行，省下的是准备时间，增加的却是清理、审计和回滚成本。

如果你需要临时算力、持续在线的编码环境，或想让团队先做一轮隔离试点，租赁 MacHTML 的云端 Mac 会更容易把环境独立出来、按任务交付并在结束后重置。先下载或保存这份部署验收思路，在非生产仓库完成权限、回滚和中断恢复测试；只有当主力设备确实无法稳定在线时，再把长任务迁移到云端 Mac。

常见问题