OpenAI 在本周更新的 Codex 企业文档里，悄悄上线了一项对自动化工程师来说相当实用的能力：ChatGPT Business 和 Enterprise 工作区现在可以创建 Codex Access Token，用来让脚本、CI Runner、定时任务以工作区成员的身份非交互式地跑 Codex。
这事儿听起来不大，但解决的是一个相当具体的痛点——过去你想在流水线里跑 codex exec，要么得用 Platform 上的 API Key（那是另一套计费、另一套权限），要么得让某个员工在 Runner 上完成一次浏览器登录，然后祈祷会话别过期。两条路都不优雅。Access Token 把这层尴尬抹平了。
这是个什么东西
按照 OpenAI 的官方定义，Codex Access Token 是"允许受信任的自动化以 ChatGPT 工作区身份运行本地 Codex"的凭据。三个关键词得拆开看：
- 受信任的自动化：不是给公网随便调用的，OpenAI 明确警告别在公共 CI、来自 fork 的 PR、或者共享机器上使用。
- ChatGPT 工作区身份：这是它和 Platform API Key 最本质的区别。Token 绑定到创建它的那个 ChatGPT 用户和工作区，所有调用都会走工作区的治理、配额和审计链路。
- 本地 Codex：注意是
codex exec这种本地 CLI 形态，不是给你做通用 OpenAI API 调用用的。
创建入口在 ChatGPT 管理控制台的 Access Tokens 页面。目前仅 Business 和 Enterprise 套餐可见，Team 套餐暂未在文档列出（社区有用户在 linux.do 上确认 Team 工作区的管理面板里也已经看到入口，但 OpenAI 官方文档目前只标注了 Business 和 Enterprise）。
为什么不直接用 API Key
这是开发者最容易困惑的一点。OpenAI 在文档里给了一句相当干脆的判断：
如果 Platform API 密钥适用于你的自动化，请继续使用 API 密钥认证。
换句话说，Access Token 不是 API Key 的升级版，而是补充——它专门为那些必须以 ChatGPT 工作区身份运行的场景而生。具体差异可以这么理解：
| 维度 | Platform API Key | Codex Access Token |
|---|---|---|
| 归属 | API 组织 | ChatGPT 工作区用户 |
| 计费 | Platform 按量计费 | 走 ChatGPT 订阅权益 |
| 审计 | Platform 控制台 | ChatGPT 工作区治理 |
| 适用 | 通用 API 调用 | 本地 Codex 自动化 |
| 权限模型 | 组织级 | 用户级，继承工作区策略 |
举个具体的例子：你们公司买的是 ChatGPT Enterprise，包含了 Codex 的使用配额，老板希望工程师在 CI 里跑代码生成、自动化重构这类任务时，用量能挂在 ChatGPT 订阅而不是再开一份 Platform 账单——这就是 Access Token 存在的理由。它让"ChatGPT 订阅里的 Codex 权益"第一次能被程序化消费。
一个典型用法
文档里点名的几个场景，都是工程团队的日常：
# 在 CI 里运行一次性的代码生成任务
export CODEX_ACCESS_TOKEN="your-token-here"
codex exec "refactor src/auth/ to use the new SessionStore API" \
--working-dir ./repo \
--output-format patch
或者把它放进定时任务里，每天凌晨跑一轮代码审查、生成 changelog、补测试用例。Codex 在运行开始时校验 Token，把这次运行关联到对应的工作区身份，之后管理员就能在工作区治理后台看到"谁的 Token、跑了什么、消耗了多少"。
这种把使用记录汇总到组织视图的能力，对企业来说价值不小。过去 API Key 的审计是"组织 vs 组织"，而工作区身份能落到具体的人——出了问题能找到负责人，配额超了能定位到团队。
安全模型：把它当 SSH Key 一样对待
OpenAI 在文档里花了不小篇幅讲风险，几乎是按照"密钥管理最佳实践"教科书来的：
- 泄露即沦陷：任何拿到 Token 的人都能以你的身份启动 Codex 运行，所以必须放进密钥管理器（Vault、AWS Secrets Manager、1Password Secrets Automation 之类），不要写日志，不要 commit 到仓库。
- 不要用在不可信 Runner 上：公共 CI、来自 fork 的 PR、共享的开发机——这三类场景被点名警告。fork PR 这条尤其值得 GitHub Actions 用户注意，默认的 secrets 行为虽然会拦截 fork PR，但配置错了就是灾难。
- 一人一 Token，别共享：文档里明确建议"为特定工作流负责人创建令牌"，避免一个 Token 被多个不相关团队复用导致审计混乱。
- 设定有效期：长期有效的 Token 在工作流变更后可能还活着，OpenAI 建议"优先使用有限期限，并撤销不再使用的令牌"。
这套话术对老 DevOps 来说没什么新鲜的，但对于一些长期只用 ChatGPT 网页版、刚开始接触自动化的企业用户，确实是必要的提醒。Token 的等级和危险性，基本可以对标 GitHub 的 Personal Access Token——你不会拿 PAT 去 fork PR 里用，对吧。
一个被忽视的细节：身份归属
这里有个值得展开的点：Access Token 是绑定到具体用户的，不是工作区共享的。这意味着：
- 如果创建 Token 的员工离职，这个 Token 应该跟着废掉。
- Token 消耗的是该用户在工作区里的 Codex 配额（如果工作区设置了人均限额的话）。
- 治理日志里这次运行会归到这个用户名下。
这种设计和很多企业 SaaS 的"机器人账号"思路不同——OpenAI 没有引入独立的 service account 概念，而是让"自动化"借用一个真实用户的身份去跑。好处是治理简单、责任清晰；代价是组织得自己想清楚"谁是这个自动化的负责人"。
社区里已经有人在讨论这个设计的边界。比如：如果一个团队的 CI 流水线由整个团队维护，应该挂在谁名下？OpenAI 的建议是"为特定工作流负责人创建令牌"——也就是把自动化的所有权显式落到某个人头上，而不是搞模糊的共享。这其实和现代 SRE 团队推崇的 "on-call ownership" 思路一致：每个自动化都得有主。
它意味着什么
把视角拉远一点看，Codex Access Token 的上线是 OpenAI 把 Codex 从"个人开发者的 CLI 玩具"推向"企业生产工具"过程中的一个必要拼图。在这之前，Codex 在企业里的使用基本依赖个人会话，缺乏机器对机器的稳定接入方式；现在补上了，意味着以下几类工作流可以正经搬上 CI：
- 自动化代码审查（每个 PR 触发 Codex 跑一遍）
- 大规模仓库重构（用脚本批量调用 Codex 处理多个目录）
- 文档/测试生成的定时任务
- 内部工具链中的代码生成步骤
对比 Anthropic 的 Claude Code 和 GitHub 自家的 Copilot CLI，Codex 这次补的是企业治理那一段——不是技术能力上的领先，而是"让企业 IT 部门敢批准这个东西进生产"的那种合规性补强。这种活儿不性感，但是必须做。
值得一提的是，目前 Codex Access Token 的生效范围限定在 ChatGPT Business 和 Enterprise，对于个人开发者和大部分中小团队，仍然要通过 Platform API Key 走标准 OpenAI API 调用。如果你的项目想低门槛对接 GPT、Claude、Gemini、DeepSeek 等多家模型，又不想为每家单独申请、单独管理账单，类似 OpenAI Hub 这种聚合平台可以用一个 Key 兼容 OpenAI 格式直连国内访问，是另一条思路——和 Codex Access Token 解决的不是同一个问题，但在选型时可以一起考虑。
几个还没说清楚的问题
文档目前留了一些没明说的细节，开发者在落地时可能会撞上：
- Token 的有效期上限是多少？ 文档建议"优先使用有限期限"，但没给出系统支持的最大有效期。
- 轮换有没有 API？ 目前看 Token 创建是控制台操作，自动化轮换的程度还不清楚。
- 配额怎么算？ Codex 在 ChatGPT Business 里有什么样的人均/工作区配额，超出后的行为是什么——这部分需要管理员到自己的工作区设置里确认。
- 和 Platform API Key 同时使用会冲突吗？ 文档没明说，但从设计上看两者走不同链路，应该可以共存。
这些问题预计会在后续文档迭代里补全，社区里也已经有用户开始测试 Token 在不同 CI 平台（GitHub Actions、GitLab CI、Buildkite）上的行为差异。如果你的团队是 ChatGPT Business 或 Enterprise 用户，这个能力值得在下一次自动化迭代时纳入评估——把 Codex 的用量从"每个人浏览器里散着"收回到"工作区统一管理"，光是这一点对企业 IT 来说就够动力上车了。
参考来源
- ChatGPT Business/Team 现在可以创建 Codex Access Token 了 - linux.do — 国内开发者社区对此次更新的第一手讨论与控制台截图
- awesome-ChatGPT-repositories - GitHub — ChatGPT 相关开源生态聚合，可参考社区围绕 Codex CLI 的项目动态