古法编程

OpenAI Codex access tokens 适合脚本、定时任务和 CI runner 做非交互式的 Codex local 访问，并且可以把运行记录关联到 ChatGPT workspace 身份。前提是 workspace 已启用 Codex Local 与 access token 权限；创建后只能立即复制一次，过期或撤销后不能再启动新的 Codex runs。

OpenAI Codex Access Token 创建与使用

OpenAI Codex access tokens 用来让受信任的自动化以 ChatGPT workspace 身份运行 Codex local。适合脚本、定时任务、CI runner 这类需要重复执行、不中断登录的场景。

这项能力目前只支持 ChatGPT Business 和 Enterprise workspaces。

Access tokens 在 ChatGPT admin console 的 Access tokens 页面创建。它们会绑定到创建它的 ChatGPT 用户和 workspace，Codex 会把它们当作程序化本地工作流的 agent identity 使用。

如果你的自动化已经能用 Platform API key，就继续用 API key auth。只有在工作流明确需要 ChatGPT workspace access、ChatGPT-managed Codex entitlements，或 enterprise workspace controls 时，才用 Codex access tokens。

Access tokens 的工作方式

当 Codex 需要在没有用户浏览器登录的情况下运行时，就用 access token。这个 token 代表创建它的 ChatGPT workspace 用户，所以运行结果可以使用该用户的 Codex access，并出现在 workspace governance data 里。

Codex 会在 run 开始时检查 token，并把该 run 关联到对应的 workspace identity。把它当作普通 automation secret 处理：放进 secret manager，避免进入日志，定期轮换。

Access token 适合这些场景：

  • codex exec 作业，运行在受信任的 automation 上。
  • 需要重复执行、非交互式 Codex runs 的本地脚本。
  • 需要把用量关联到 ChatGPT workspace user，而不是 API organization key 的 enterprise workflow。

主要风险包括：

  • Leaked secrets: 拿到 token 的人都可以以 token 创建者身份启动 Codex runs。要把 token 存进 secret manager，避免写入日志，并定期轮换。
  • Untrusted runners: public CI、forked pull requests、共享机器可能把 token 暴露给 workspace 外的人。只在 trusted runners 上使用 access tokens。
  • Shared identities: 把一个人的 token 复用到多个不相关团队，会让 ownership 和 audit trail 更难判断。最好为特定 workflow owner 单独创建 token。
  • Stale credentials: 长期有效的 token 可能在 workflow 变化后仍然有效。优先使用有限期，停用不再使用的 token。
  • Wrong credential type: access tokens 只用于 Codex local workflows。一般 OpenAI API calls 仍然用 Platform API keys。

怎么启用 access token 创建权限

需要先在 workspace settings 里开启 Codex Local 控制项，允许指定成员创建 access token。

  1. 打开 Workspace Settings > Settings and Permissions。
  2. 在 Codex Local 区域，确认 Allow members to use Codex Local 已开启。
  3. 如果希望所有被允许的成员都能创建 access token，再开启 Allow members to use Codex access tokens。
  4. 如果你使用 custom roles 做更小范围的 rollout，只把 access token permission 分配给确实需要创建 token 的 groups。

Access token 创建权限建议只给清楚知道 token 存放位置、使用哪个 automation、以及如何轮换的人或 service owner。

怎么创建 access token

使用 Access tokens 页面给 token 命名，并选择过期时间。

  1. 打开 Access tokens。

  2. 选择 Create。

  3. 输入一个描述性名称，例如 release-ci 或 nightly-docs-check。

  4. 选择 expiration。建议使用有限期，比如 7、30、60 或 90 天。如果选择 No expiration，就要定期轮换 token。

  5. 选择 Create。

  6. 立即复制生成的 access token。关闭弹窗后就不能再次查看。

  7. 把 token 存到 secret manager 或 CI secret store。

最短的自定义有效期是一天。已撤销和已过期的 token 不能再用于启动新的 Codex runs。

怎么在 Codex CLI 中使用 access token

如果是临时自动化，把 token 放到 CODEX_ACCESS_TOKEN，然后正常运行 Codex：

export CODEX_ACCESS_TOKEN="<access-token>"
codex exec --json "review this repository and summarize the top risks"

如果想做本地持久登录，可以把 token 通过管道传给 codex login --with-access-token：

printf '%s' "$CODEX_ACCESS_TOKEN" | codex login --with-access-token
codex exec "summarize the last release diff"

codex login --with-access-token 会把 agent identity credential 存到 Codex auth storage。若不希望把凭据持久化到机器上，就用 CODEX_ACCESS_TOKEN 环境变量。

怎么轮换或撤销 token

Access token 的轮换方式和其他 automation secrets 一样：

  1. 创建一个替换用 token。
  2. 更新 runner、scheduler 或 secret manager 里的 secret。
  3. 用新 token 做一次 smoke test。
  4. 在 Access tokens 页面撤销旧 token。

在 Access tokens 页面中，workspace owners 和 admins 可以撤销 workspace 内任意 token。拥有 access token permission 的成员只能撤销自己创建的 token。

权限模型

Access token permission 和一般的 Codex local permission 是分开的。成员可以拥有 Codex app、CLI 或 IDE extension 的访问权，但并不代表可以创建 access token。

Capability Workspace owners and admins Member with access token permission Member without access token permission
Open Access tokens Yes Yes No
Create access tokens Yes, for their own ChatGPT workspace identity Yes, for their own ChatGPT workspace identity No
List access tokens Workspace list, including who created each token Only tokens they created No
Revoke access tokens from the Access tokens page Any token in the workspace Only tokens they created No page access
Grant or remove access token permission Yes No No
Manage other Codex enterprise settings Yes, based on admin role and Codex admin permissions No, unless separately granted No

简而言之：workspace owners 和 admins 管理的是 workspace 级别的访问控制。成员如果要创建和管理自己的 token，必须有 access token permission，但这个权限不会变成 admin rights，也看不到其他成员的 token。

The access tokens page returns 404 or forbidden 怎么解决

如果 Access tokens 页面返回 404 或 forbidden，先让 workspace owner 或 admin 确认两件事：Codex access tokens 是否已启用，你的 role 是否包含 access token permission。

codex login --with-access-token fails 怎么解决

先确认你复制的是生成出来的 access token，不是 browser session token，也不是 Platform API key。再确认 token 没有过期，也没有被撤销。

相关文档

常见问题

OpenAI Codex access token 怎么创建

先确认 workspace 已开启 Allow members to use Codex Local，并且你有 access token permission。然后打开 Access tokens 页面，点 Create，填写名称和过期时间，创建后立刻复制并保存。

OpenAI Codex access token 可以用在哪些场景

它适合 codex exec、本地脚本和 CI runner 这类非交互式 Codex local workflows。若只是一般的 OpenAI API calls，还是优先用 Platform API key。

为什么 Access tokens 页面会显示 404 或 forbidden

通常是 workspace 没有启用 Codex access tokens，或者你的 role 没有 access token permission。让 workspace owner 或 admin 检查 workspace settings 和你的权限分配。