内容阅读

安装、认证和审批模式：从第一次运行到安全基线

TL;DR

安装 Codex 只是开始。真正需要团队认真设计的是认证方式、工作区信任、沙箱模式、审批策略、网络访问和密钥边界。Codex 不是普通命令行工具，它会根据任务读取文件、编辑文件、运行命令，并在权限不足时请求提升。第一次引入团队时，不要追求“少弹窗”，先建立可解释的安全基线。

OpenAI 官方 quickstart 在 2026-06-22 可访问版本中列出 Codex App、IDE 扩展和 CLI 的安装路径。CLI 支持 macOS、Windows 和 Linux；CLI 可通过官方安装脚本、npm 或 Homebrew 安装；运行 codex 后可使用 ChatGPT 账号或 OpenAI API key 登录，文档同时提醒 API key 登录可能导致部分功能不可用。官方安全文档给出常见沙箱和审批组合：workspace-write + on-request 适合受控本地编辑，read-only + on-request 适合只读浏览，read-only + never 适合非交互只读 CI，危险全访问模式不建议日常使用。

读者定位

本文面向准备在个人机器、团队仓库、远程环境或 CI 中使用 Codex 的开发者和技术负责人。你可能已经能运行 codex，但还没有回答这些问题：团队默认用什么登录方式？哪些目录可以写？安装依赖是否要审批？网络默认开还是关？谁能让 Codex 改 GitHub Actions？API key 能不能出现在 prompt 或日志里？

如果这些问题没有提前约定，Codex 的第一次成功很可能来自权限过宽，而不是流程合理。短期看省事，长期看会让事故排查、审计和团队推广变难。

问题：安装成功不等于可以安全使用

普通 CLI 工具通常执行你输入的命令。Codex 不同，它会在任务过程中自行选择读哪些文件、改哪些文件、运行哪些命令，并可能请求网络或工作区外权限。一个模糊任务可能触发 npm install、数据库迁移、删除生成文件、访问外部文档、修改 CI 配置。安装完成后直接放开权限，相当于让一个还不了解团队边界的代理坐到生产级工作台前。

认证也不是小事。ChatGPT 登录、API key、访问令牌、CI secret、企业管理策略会影响可用能力和审计路径。官方 quickstart 明确说明 Codex 可用 ChatGPT 账号或 API key 登录，并提示 API key 登录时某些功能可能不可用。团队文档不应该只写“登录 Codex”，而要说明不同场景采用哪种认证方式。

审批模式更容易被误解。很多人把审批看成打断效率的弹窗。其实审批是授权边界：哪些动作可以自动执行，哪些动作需要人类确认。和沙箱配合后，它决定了 Codex 的错误判断最多能造成多大影响。

心智模型：三道门和两条记录

可以把 Codex 的安全基线看成三道门。

第一道是身份门。谁在使用 Codex？是个人 ChatGPT 账号、OpenAI API key、自动化访问令牌，还是企业管理的身份？身份决定额度、权限、审计和可用功能。个人实验可以简单，团队落地必须能解释“这个任务是谁授权的”。

第二道是空间门。Codex 能读写哪些路径？read-only 只允许读；workspace-write 允许在工作区写；危险全访问会突破常规保护。官方安全文档还说明，在默认 workspace-write 中，.git、.agents、.codex 等受保护路径仍为只读。这个细节很重要：工作区可写不等于仓库内部所有内容都可写。

第三道是动作门。Codex 可以自动运行哪些命令？什么时候需要审批？是否能访问网络？是否能安装依赖、推送代码、运行部署、写出工作区？这些不是 prompt 风格问题，而是执行策略。

两条记录也要保留。第一条是版本记录：Git 分支、checkpoint、diff、PR。第二条是执行记录：运行过的命令、失败输出、审批动作、最终摘要。没有记录，Codex 的修改就很难被团队复盘。

详细机制：安装、登录、沙箱、审批和网络

安装

官方 quickstart 给出几种 CLI 安装方式。macOS 或 Linux 可使用官方安装脚本：

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

Windows 可使用 PowerShell 安装脚本：

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

也可以通过 npm 或 Homebrew：

npm install -g @openai/codex
brew install --cask codex

团队文档应该选定推荐方式。不要把某个开发者机器上的临时安装命令写成通用标准。对于自动化安装，官方文档提到可设置 CODEX_NON_INTERACTIVE=1，这适合脚本场景，但也意味着团队要明确版本升级和供应链验证策略。

沙箱

沙箱决定 Codex 技术上能做什么。官方安全文档给出常见组合：

--sandbox workspace-write --ask-for-approval on-request：Codex 可读文件、编辑工作区、在工作区运行命令；写出工作区或访问网络需要审批。
--sandbox read-only --ask-for-approval on-request：Codex 可读文件并回答问题；编辑、运行命令或访问网络需要审批。
--sandbox read-only --ask-for-approval never：只读且不请求审批，适合非交互只读 CI。
--sandbox workspace-write --ask-for-approval untrusted：可读写文件，但运行不受信命令前请求审批。
--dangerously-bypass-approvals-and-sandbox 或 --yolo：无沙箱、无审批，官方标为不推荐的高风险模式。

默认建议：真实 Git 仓库中的日常本地任务从 workspace-write + on-request 开始；只读调研从 read-only + on-request 开始；CI 里的只读检查从 read-only + never 开始。全访问模式只应在外层已有强隔离的临时容器或虚拟机中使用，并且任务本身允许不可逆风险。

审批

审批不是“同意一切”的按钮。每次审批都应回答三个问题：这个动作是否必要？是否符合当前任务？失败后能否回滚？

需要特别谨慎的审批包括：

安装依赖或运行包管理器写 lockfile。
访问外部网络或下载脚本。
写出工作区或访问用户目录。
删除文件、移动目录、批量格式化。
修改 GitHub Actions、部署脚本、权限配置。
推送分支、发布包、部署服务。
读取或写入 secrets、.env、凭据文件。

如果 Codex 请求的动作和任务目标关系不清，应拒绝并要求它解释原因或提供替代方案。

网络

网络访问要分两层看：Codex 的 web search 工具和被它启动的命令访问网络。官方安全文档说明 web search 可有 cached、disabled、live 等模式；命令网络访问又受 sandbox 和 network proxy 配置影响。团队不要用一句“允许联网”概括所有网络行为。

常见策略是：默认禁止命令直接联网；需要查官方文档时允许受控搜索；需要安装依赖时要求明确包管理器、registry、lockfile 影响和回滚方式；生产服务、内网地址、云元数据、数据库等默认不允许访问。

真实工作流案例：第一次在团队仓库试运行

不要把第一次试运行交给复杂重构。可以用四步建立信任。

第一步，只读确认上下文：

请阅读 README、package.json 和 AGENTS.md，总结项目结构、常用命令和安全边界。
不要修改文件，不要运行命令。

第二步，受控运行一个无副作用命令：

请说明你准备运行哪个 lint 或 test 命令，以及它是否会写文件。
等我确认后再运行。

第三步，低风险修改：

修正文档中的一个过期命令。只改 docs/setup.md。
不要修改代码，不要安装依赖。完成后汇报 diff。

第四步，验证和复盘：

请总结本次任务读取了哪些文件、修改了哪些文件、运行了哪些命令、
哪些命令未运行，以及你认为当前 AGENTS.md 还缺什么规则。

这套流程看似慢，但能暴露真正的问题：AGENTS.md 是否可读，命令是否准确，审批是否合适，Codex 是否会越界，团队是否能理解最终摘要。

操作清单：安全基线模板

安装方式：团队推荐官方安装脚本、npm、Homebrew 或企业分发中的一种，并写明升级策略。
登录方式：区分个人开发、自动化、CI 和企业环境，不混用个人 key 和团队 secret。
默认目录：只在 Git 仓库或可回滚临时目录中授权可写任务。
默认沙箱：本地写代码使用 workspace-write + on-request，只读调研使用 read-only + on-request。
网络策略：默认不让命令联网；外部文档、依赖安装、下载脚本都需单独授权。
受保护事项：.env*、secrets、生产配置、迁移文件、CI 权限、部署脚本、账单和权限逻辑默认需人工确认。
执行记录：要求 Codex 汇报命令、验证结果、失败项和剩余风险。
回退路径：任务前确认分支、checkpoint 或干净工作区。

权衡与风险

保守配置会降低速度。安装依赖、联网查资料、写出工作区、运行生成脚本时，审批会打断任务。对个人探索来说，这种打断可能烦；对团队仓库来说，它是把错误限制在可理解范围内的成本。

宽松配置会提高吞吐，但需要外层隔离。比如在一次性 dev container、临时 VM、无生产凭据的 fork 仓库中，放宽部分权限可能合理。关键是不要把“环境已经隔离”说成口头假设，要在文档里写清楚隔离方式和销毁方式。

API key 认证方便自动化，但可能没有 ChatGPT 登录可用的全部功能。官方文档已经提示 API key 登录会有功能差异。团队不要在不确认功能边界的情况下，把 API key 当成所有入口的统一方案。

常见误区

误区一：能安装并运行就算接入完成。真正的接入完成，是团队知道如何登录、如何授权、如何回滚、如何审查。

误区二：为了效率直接开 --yolo。危险全访问会绕过沙箱和审批。除非外层环境已经是可销毁隔离环境，并且任务允许这种风险，否则不要把它写进日常规范。

误区三：把网络访问和 web search 混为一谈。允许 Codex 搜索官方文档，不等于允许它运行任意命令访问公网；允许 npm install，也不等于允许访问生产服务。

误区四：把密钥贴进 prompt。Prompt、日志、会话记录和最终摘要都可能扩大密钥暴露面。凭据应通过受控 secret 管理，不应作为文本材料交给模型。

误区五：认为 read-only 就没有风险。只读也可能泄露代码结构、日志和配置内容。敏感仓库仍要关注谁能发起任务、输出保存在哪里、外部工具是否可见。

团队落地：权限基线的分级方案

安全基线最好不要只有一个档位。所有任务都用最保守配置，效率会低；所有任务都用宽松配置，风险会被放大。更可维护的做法是按任务类型定义几组 profile 或操作规范，让开发者知道什么时候选择哪一组。

第一档是只读分析。适合代码理解、风险调查、计划生成、review 前解释 diff。推荐 read-only + on-request，如果在非交互自动化里只做读取，可以用 read-only + never。这档任务的 prompt 要写清“不修改文件”。如果 Codex 请求编辑或运行有副作用命令，默认拒绝，并要求它解释为什么只读无法完成。

第二档是受控本地编辑。适合日常 bug 修复、补测试、文档更新、小范围重构。推荐 workspace-write + on-request。这档允许 Codex 在工作区内编辑和运行常规命令，但写出工作区、访问网络、安装依赖、删除文件、执行发布动作都应触发审批。多数团队的日常开发可以以这档为默认。

第三档是自动化只读或低风险批处理。适合 CI 中让 Codex 总结失败、检查规则、生成建议，不直接改仓库。这里要特别谨慎 --ask-for-approval never：它适合不会请求人工审批的环境，但也意味着任务如果需要权限会直接失败。不要把 never 和高权限沙箱组合在一起当作“省事模式”。

第四档是隔离环境中的高权限实验。只有在一次性容器、临时 VM、无生产凭据、无持久数据、可销毁工作区中，才考虑放宽到更高权限。即使这样，也要限制任务范围和网络目标。危险全访问模式不应该出现在普通开发机和真实业务仓库的常用说明中。

分级之外，还要管理审批习惯。开发者看到审批请求时，不应机械点击同意。一个合格审批请求应说明要执行什么、为什么需要、可能写哪些文件、失败后如何处理。如果请求是“运行安装脚本”“访问外部网络”“删除目录”“推送分支”，但任务 brief 没提到这些动作，应该要求 Codex 先回到 Plan。

密钥处理要单独成章。不要把 API key、cookie、数据库密码、云平台令牌贴给 Codex。即使当前会话看似安全，也会进入日志、摘要或上下文。需要凭据的自动化任务，应使用 CI secret、受管环境变量或官方支持的访问令牌。任务描述里只写“需要某类权限”，不写实际值。若 Codex 要求查看 .env，默认拒绝，除非这是专门授权的安全审计任务。

网络策略也要分级。查官方文档、下载依赖、访问私有 registry、访问内网服务、访问生产 API 是不同风险。团队可以规定：官方文档搜索可在确认后允许；依赖安装必须说明 lockfile 影响；内网和生产服务默认禁止；外部脚本下载需要人工复制审查，不让 Codex 直接 curl 后执行。

最后要记录每次越权。不是为了追责，而是为了改进规则。如果某类任务总是需要联网，就在任务模板里提前写；如果某个测试总要写临时目录，就把可写路径纳入说明；如果某个审批经常被拒绝，说明 Codex 的计划或 AGENTS.md 缺少边界。权限基线不是静态墙，而是根据真实执行经验校准的护栏。

审批实战：哪些请求应该停下来

审批的难点不在于会不会点击同意，而在于判断请求背后的工程含义。Codex 可能用一句简短说明请求运行命令，但 reviewer 需要理解这个命令会读什么、写什么、联网到哪里、是否改变仓库状态。团队可以把常见请求分成几类处理。

第一类是只读命令，例如 git status、rg、读取文件、列目录。这类通常风险低，但仍要看是否会读取敏感目录。只读不代表无风险，尤其在含有凭据、客户数据、私有日志的仓库中。对普通代码仓库，这类命令可以自动化；对敏感仓库，要明确可读范围。

第二类是构建和测试命令，例如 pnpm test、cargo test、pytest。这类看似安全，但可能生成缓存、快照、覆盖率文件、临时数据库或网络请求。审批时要看命令是否在项目文档中，是否会写文件，是否需要外部服务。若测试会改快照，应该让 Codex 先说明原因。

第三类是依赖命令，例如 npm install、pip install、brew install、下载二进制。这类应该谨慎。它们会修改 lockfile、访问 registry、执行安装脚本，甚至改变全局环境。只有任务明确需要依赖，并且说明包名、来源、版本和影响时，才考虑批准。普通代码修改不应随意安装新依赖。

第四类是网络命令，例如 curl、wget、访问文档站、调用外部 API。访问官方文档和访问生产接口是完全不同的风险。审批时要看目标域名、请求内容、是否携带凭据、是否会执行下载内容。下载后立即执行脚本是高风险动作，除非来源和完整性都可验证。

第五类是破坏性文件命令，例如删除、移动、批量格式化、重命名目录。这类要先看当前 Git 状态和任务范围。删除生成文件可能合理，删除源文件就需要计划。批量格式化可能掩盖真实改动，影响 review。没有明确 Done-when 时，不要批准大范围文件操作。

第六类是 Git 操作，例如 commit、push、reset、checkout、rebase、stash。Codex 可以帮助准备提交信息或解释 diff，但真正改变历史、推送远端、丢弃改动的命令要非常谨慎。尤其在多人并行工作区里，Git 操作可能影响其他人或其他 worker 的未完成改动。

第七类是部署和发布命令，例如 deploy、publish、release、terraform apply、kubectl apply。默认不批准，除非任务就是受控发布，并且有明确环境、审批链、回滚方案和负责人。Codex 的日常工程任务不应顺手触发真实发布。

第八类是凭据相关动作，例如读取 .env、修改 secrets、旋转 key、查看云平台配置。这类请求通常要拒绝，并要求改用受管 secret 或人工操作。即使 Codex 只是“为了调试”，也不应把敏感值放进会话上下文。

把这些审批类别写进团队规范后，开发者面对请求时会更稳定。审批不是阻碍 Codex，而是把代理动作转化为人类可理解的授权。一个审批被拒绝，也不是任务失败；它只是提醒任务需要回到计划、缩小范围或换验证方式。

最小可用安全手册示例

团队可以把下面这类短手册放进内部文档，作为第一次接入 Codex 的默认说明。它不追求覆盖所有场景，而是给开发者一个不会过度放权的起点。

本地开发默认在 Git 仓库根目录运行 Codex。开始前先看 git status --short，确认当前工作区里哪些改动属于自己，哪些属于他人或其他任务。若工作区已经有不相关改动，不要求 Codex 清理，不让它 reset，不让它重排无关文件。

只读任务使用 read-only。典型任务包括解释代码、列风险、做计划、总结 diff、审查测试覆盖。Prompt 第一行写“不要修改文件”。如果 Codex 请求写权限，除非你决定升级任务阶段，否则拒绝。

普通编辑任务使用 workspace-write 加 on-request。典型任务包括修小 bug、补测试、更新文档、局部重构。任务必须写清允许修改范围和 Done-when。Codex 可以运行项目已有命令，但安装依赖、联网、删除文件、改 CI、推送代码都要单独解释并审批。

高风险任务不直接执行。认证、权限、账单、数据迁移、生产配置、部署发布、GitHub Actions secrets，默认先只读调查或给计划。计划必须说明将修改哪些文件、如何验证、哪些事项需要 owner 确认。没有计划，不给写权限。

凭据不进对话。开发者不得把 API key、cookie、数据库密码、云平台令牌贴给 Codex。Codex 不应读取 .env*，除非任务就是经授权的安全检查，并且输出中不得包含实际值。需要凭据的命令由人类通过受管环境注入。

网络默认受控。查官方文档可以请求允许；安装依赖要说明包名、版本和 lockfile 影响；访问内网、生产服务、云元数据地址默认禁止。下载脚本后直接执行属于高风险动作，需人工审查来源。

结束时必须汇报。无论任务大小，Codex 都要说明修改文件、运行命令、命令结果、未运行检查和剩余风险。若某项检查因环境缺失无法运行，必须写明人工验证建议。没有汇报，不算完成。

这份手册可以先很短，然后根据实际审批记录迭代。团队不需要一开始设计完美权限体系，但必须避免把全访问当默认，把密钥当文本，把审批当确认弹窗。

延伸阅读

GitHub 原文：02-setup-auth-approval-modes.md

0 条

登录后可以参与评论和讨论。

去登录

还没有评论

欢迎留下第一条评论，帮助这篇内容更快形成讨论。