近两年，Vibe Coding越来越活，市面上的AI编程工具也越来越多。国外有鼎鼎大名的Claude Code、Codex、Gemini等，国内Qwen Code、Doubao-Seed-Code、Deep Code等等。今天我们以Codex为例，来聊聊AI编程工具的初始登录与配置。

许多人第一次用 Codex，最关心的是一句话：

到底怎么登录？API Key 放哪？服务器没浏览器怎么办？它会不会乱改我电脑上的文件？

这些问题看似是安装配置问题，实际上是 AI 编程能不能安全落地的第一道门槛。

Codex 不是一个普通聊天窗口，而是一个可以读项目、改代码、跑命令的本地编码智能体。OpenAI 官方对 Codex 的定位就是“运行在你本地终端里的 coding agent”，它可以写代码、理解代码库、审查代码、调试问题和自动化开发任务。

所以，Codex 的配置不能只看“能不能跑起来”，更要看三件事：

身份怎么认证，密钥怎么保存，权限边界怎么控制。

一、Codex主要有三种认证方式

目前使用 OpenAI 模型时，Codex 支持两类常规登录方式：ChatGPT账号登录和API Key登录。其中 Codex Cloud 需要 ChatGPT 登录，而 Codex CLI 和 IDE 扩展两种方式都支持。

1. ChatGPT登录：适合个人日常开发

最简单的方式就是直接运行：

codex

或者：

codex login

如果当前没有有效会话，Codex CLI 默认会走 ChatGPT 登录流程，打开浏览器完成 OAuth 授权。登录完成后，浏览器会把访问令牌返回给 CLI 或 IDE 扩展。

这种方式适合什么人？

适合已经有 ChatGPT Plus、Pro、Business、Edu、Enterprise 等账号的用户。OpenAI 官方也提议用户用自己的 ChatGPT 账号登录 Codex，把它作为订阅权益的一部分使用。

它的好处是：体验顺滑，适合日常开发；缺点是：在服务器、CI/CD、自动化脚本里不必定方便。

2. API Key登录：适合脚本、服务器和自动化

如果你希望按 OpenAI Platform API 用量计费，或者要在服务器环境、CI/CD环境里使用 Codex，更推荐 API Key。

先设置环境变量：

export OPENAI_API_KEY="sk-你的key"

然后执行：

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

Codex CLI 官方命令说明里明确支持 codex login –with-api-key，它会从标准输入读取 API Key。

Windows PowerShell 可以这样写：

$env:OPENAI_API_KEY="sk-你的key"
Write-Output $env:OPENAI_API_KEY | codex login --with-api-key

API Key 登录的优势是稳定、可自动化、适合服务器；但它走的是 OpenAI Platform 账号的 API 计费逻辑，而不是 ChatGPT 订阅额度。OpenAI 文档也明确提到，API Key 使用会按 Platform 标准 API 价格计费；某些依赖 ChatGPT credits 的能力只在 ChatGPT 登录下可用。

3. Access Token：企业自动化场景更合适

如果是 ChatGPT Business 或 Enterprise 工作区，管理员可以开启 Codex Access Token，用于可信脚本、调度任务、私有 CI runner 等非交互式工作流。OpenAI 官方说明中，Access Token 适合需要以 ChatGPT workspace 身份运行 Codex 的场景，而不是普通 OpenAI API 调用。

临时使用：

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

持久登录：

printf '%s' "$CODEX_ACCESS_TOKEN" | codex login --with-access-token

如果不想在机器上持久保存凭据，就只放在 CODEX_ACCESS_TOKEN 环境变量里临时使用。OpenAI 文档也提醒，Access Token 应像其他自动化密钥一样放在 secret manager 中，避免写入日志并定期轮换。

二、Codex的登录信息到底保存在哪？

许多人配置 Codex 时最容易忽略这一点：
登录成功，不代表密钥消失了，它只是被缓存到了本地。

Codex 的本地状态默认放在：

~/.codex

也可以通过 CODEX_HOME 改变位置。官方文档说明，CODEX_HOME 默认是 ~/.codex，常见文件包括：

~/.codex/config.toml
~/.codex/auth.json
~/.codex/history.jsonl
日志、缓存等其他状态文件

其中 config.toml 是本地配置文件；如果使用文件型凭据存储，auth.json 会保存认证信息；如果启用了系统凭据存储，则可能进入操作系统的 keychain/keyring。

也就是说，Codex 的凭据可能有两种保存方式：

cli_auth_credentials_store = "file"

或者：

cli_auth_credentials_store = "keyring"

还可以：

cli_auth_credentials_store = "auto"

官方说明中，file 会把凭据存到 CODEX_HOME 下的 auth.json，keyring 会存入操作系统凭据库，auto 则优先使用系统凭据库，不可用时再回退到 auth.json。

我个人更提议：

日常个人电脑优先用：

cli_auth_credentials_store = "keyring"

服务器、CI、容器环境可以显式使用：

cli_auth_credentials_store = "file"

但必定要注意：
~/.codex/auth.json 应该像密码一样保护。不要提交到 Git，不要截图发群，不要贴到工单里。 OpenAI 官方文档也明确提醒，文件型存储中的 auth.json 包含访问令牌，需要按密码对待。

三、环境变量怎么导入？Windows、macOS、Linux分别怎么写

配置 Codex 时，最常见的环境变量是：

OPENAI_API_KEY
CODEX_ACCESS_TOKEN
CODEX_HOME
CODEX_CA_CERTIFICATE

其中 OPENAI_API_KEY 用于 API Key 登录，CODEX_ACCESS_TOKEN 用于企业 Access Token，CODEX_HOME 用于改变 Codex 本地配置目录，CODEX_CA_CERTIFICATE 用于公司内网代理、私有根证书等场景。OpenAI 文档说明，如果企业网络使用 TLS 代理或私有根 CA，可以设置 CODEX_CA_CERTIFICATE 指向 PEM 证书包。

macOS / Linux：当前终端临时生效

export OPENAI_API_KEY="sk-你的key"
printenv OPENAI_API_KEY | codex login --with-api-key

设置 CODEX_HOME：

export CODEX_HOME="$HOME/.codex-work"

macOS / Linux：长期生效

如果你用的是 zsh：

echo 'export OPENAI_API_KEY="sk-你的key"' >> ~/.zshrc
source ~/.zshrc

如果你用的是 bash：

echo 'export OPENAI_API_KEY="sk-你的key"' >> ~/.bashrc
source ~/.bashrc

不过我不太提议把长期 API Key 明文写进 shell 配置文件。更稳妥的做法是用系统密钥管理器、企业 secret manager，或者只在需要时临时注入。

Windows PowerShell：当前窗口临时生效

$env:OPENAI_API_KEY="sk-你的key"
Write-Output $env:OPENAI_API_KEY | codex login --with-api-key

Windows PowerShell：用户级长期生效

[Environment]::SetEnvironmentVariable("OPENAI_API_KEY", "sk-你的key", "User")

设置后需要重新打开 PowerShell 才会生效。

Windows CMD：当前窗口临时生效

set OPENAI_API_KEY=sk-你的key

Windows CMD：长期生效

setx OPENAI_API_KEY "sk-你的key"

这里有一个小坑：
setx 设置后一般不会影响当前已经打开的 CMD 窗口，需要重新打开终端。

四、服务器没浏览器，Codex怎么认证？

服务器环境是 Codex 配置里最容易踩坑的地方。

由于许多服务器没有图形界面，也不能直接弹出浏览器。官方文档给了几种路径。

方案一：Device Code认证

如果你想用 ChatGPT 账号登录，又是在远程或无头环境，可以使用：

codex login --device-auth

Codex 会给出一个链接和一次性 code。你在本地电脑浏览器中打开链接，登录账号并输入 code，就能完成远程服务器上的认证。官方文档称这是 headless 设备上的首选方式，但前提是账号或工作区开启了 device code login。

方案二：API Key认证

如果只是为了在服务器上跑 Codex，最简单、最稳定的方式还是 API Key：

export OPENAI_API_KEY="sk-你的key"
printenv OPENAI_API_KEY | codex login --with-api-key

这条路径适合服务器、脚本、自动化任务、私有部署环境。

方案三：企业Access Token

如果你是 ChatGPT Business / Enterprise 工作区，并且需要让自动化任务绑定到 workspace 身份，可以使用：

export CODEX_ACCESS_TOKEN="你的token"
codex exec --json "检查当前项目并输出风险摘要"

或者：

printf '%s' "$CODEX_ACCESS_TOKEN" | codex login --with-access-token

OpenAI 官方也明确提议：如果普通 Platform API Key 能满足自动化需求，就继续用 API Key；只有当流程需要 ChatGPT workspace 权限、Codex entitlements 或企业治理能力时，再使用 Codex Access Token。

方案四：本地登录后复制auth.json

还有一种兜底方式：
先在有浏览器的电脑上运行：

codex login

确认生成：

~/.codex/auth.json

然后复制到服务器同样位置：

ssh user@remote 'mkdir -p ~/.codex'
scp ~/.codex/auth.json user@remote:~/.codex/auth.json

官方文档把它列为 headless 环境的 fallback 方法。但这条路必定要谨慎，由于 auth.json 本质上就是访问令牌缓存。

五、config.toml：真正决定Codex工作方式的地方

Codex 的许多行为不是写在命令里，而是写在：

~/.codex/config.toml

CLI 会从这个文件继承默认配置，命令行中的 -c key=value 可以覆盖本次运行的配置。官方 CLI 文档明确说明，Codex 默认从 ~/.codex/config.toml 读取配置，命令行参数优先生效。

一个适合个人开发者的简化配置可以这样写：

model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
cli_auth_credentials_store = "keyring"

[history]
persistence = "save"

服务器环境可以更谨慎一些：

approval_policy = "never"
sandbox_mode = "workspace-write"
cli_auth_credentials_store = "file"

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false
exclude = ["AWS_*", "AZURE_*", "*TOKEN*", "*SECRET*"]
include_only = ["PATH", "HOME", "OPENAI_API_KEY"]

这里特别值得讲的是 shell_environment_policy。Codex 会运行模型提出的 shell 命令，因此它会涉及“哪些环境变量可以传给子进程”的问题。官方文档说明，shell_environment_policy 可以控制 Codex 启动子进程时继承哪些环境变量，并提议通过 include、exclude、set 等方式避免泄露密钥。

这点超级重大。

许多人把 API Key、数据库密码、云厂商 AK/SK 都写在环境变量里，然后让 AI Agent 跑命令。如果没有环境变量过滤，Agent 执行的脚本、测试工具、第三方命令都有可能接触到这些敏感信息。

六、沙盒机制：Codex能不能“乱动电脑”，主要看这里

Codex 最值得重点关注的不是“它会写代码”，而是“它有能力执行动作”。

它可以读文件、改文件、运行命令。这个能力一旦没有边界，就会变得危险。

OpenAI 对 Codex 沙盒的解释很清楚：沙盒是让 Codex 在不获得整机无限权限的前提下自主工作的边界；沙盒定义它能修改哪些文件、能不能访问网络；审批策略则决定它什么时候必须停下来问你。

常见沙盒模式有三种：

codex --sandbox read-only

只读模式，适合代码解释、审查、架构分析。

codex --sandbox workspace-write

工作区可写，适合日常开发、改代码、跑测试。

codex --sandbox danger-full-access

完全放开本地沙盒限制，只提议在隔离容器、虚拟机、专用 runner 里使用。

官方 CLI 文档也特别提醒：
–dangerously-bypass-approvals-and-sandbox 会绕过审批和沙盒，只应该在外部已经加固的环境中使用；CI 或无人值守任务更推荐 –sandbox workspace-write，需要额外目录时优先用 –add-dir，不要轻易开 full access。

一个更安全的写法是：

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

如果你只想让它读代码：

codex --sandbox read-only

如果的确 需要让它访问多个目录，不要直接开全权限，可以这样：

codex --sandbox workspace-write --add-dir ../shared-lib

七、Linux、macOS、Windows的沙盒差异

Codex 沙盒在不同系统上实现方式不同。OpenAI 文档说明，macOS 使用系统内置 Seatbelt 框架；Windows 在 PowerShell 中使用原生 Windows sandbox，在 WSL2 中使用 Linux sandbox；Linux 和 WSL2 提议安装 bubblewrap。

Ubuntu / Debian：

sudo apt install bubblewrap

Fedora：

sudo dnf install bubblewrap

这意味着，如果你在 Linux 服务器上跑 Codex，别只检查 Codex 是否安装成功，还要检查沙盒依赖是否可用。

八、项目级配置：不要让陌生仓库接管你的Codex

Codex 除了读取用户级配置：

~/.codex/config.toml

还可以读取项目中的：

项目目录/.codex/config.toml

官方文档说明，Codex 会从项目根目录向当前工作目录逐层查找 .codex/config.toml，更靠近当前目录的配置优先生效；但出于安全思考，只有在项目被信任时，Codex 才会加载项目级 .codex/ 配置。并且项目配置不能覆盖凭据重定向、provider auth、本机通知/遥测等敏感设置。

这点很关键。

由于 AI 编程时代，许多人会随手 clone 一个 GitHub 项目，然后让 Codex “帮我跑起来”。如果这个项目里藏了恶意配置、恶意 hook、恶意脚本，就可能借 AI Agent 的手执行危险动作。

所以我的提议是：

第一次进入陌生项目，先用只读模式：

codex --sandbox read-only

让它先解释项目结构、依赖、启动方式。

确认可信之后，再进入：

codex --sandbox workspace-write

结尾：AI编程最重大的不仅仅是写代码，还有管权限

许多人学 AI 编程，一上来就问：“怎么让它帮我写一个系统？”

但真正用过一段时间后你会发现，AI 编程的第一课不是 prompt，也不是模型选择，而是：

认证、配置、权限、沙盒。

由于 Codex 这类工具已经不只是“回答问题”，而是在代表你操作项目。

账号登录决定它是谁；
API Key 决定谁付费；
auth.json 决定凭据在哪里；
环境变量决定它能拿到哪些秘密；
沙盒决定它能动哪里；
审批策略决定它什么时候必须停下来问你。

把这些讲清楚，Codex 才不是一个“会写代码的黑盒”，而是一个真正可以进入工程流程的 AI 编程助手。