给多个Codex代理配密钥，我把自己升职成了“批准按钮主管”|codex|命令提示符|密钥|管理器

给几个Codex代理安排真实工作后，你会发现一种特殊的乐观情绪：自己同时被提拔成了“首席批准按钮主管”。每个代理都需要一个凭证，然后是另一个。一个任务在等API令牌，另一个需要webhook密钥，而背后某个密码管理器还在礼貌地问你是否批准。再一次。

我最近花了太多时间寻找一种安全、可靠的方式，与并发的本地代理共享凭证。每个看似有希望的方案最终都会引入自己的转折：配额、并发问题、没有上下文的批准弹窗、明文文件，或者足够多的本地基础设施，让我怀疑自己是不是意外组建了一个平台团队。

1Password不是这个模式的必需品

1Password并不是本文模式的必需条件。它只是我使用的密码管理器，因此也是这个故事里出现最多的角色。更广泛的问题存在于任何秘密存储：如何给应用程序它需要的凭证，而不把每个代理操作都变成又一次前往保险库的行程？

最终奏效的答案几乎令人失望地偏向架构层面：在应用边界一次性解析秘密。让代理命令只继承一个明确的应用级允许列表。我测试了下面讨论的整套方案。有两种方法仍然足够实用，可以选用一种。

两种可用的方案

第一种：把实际值放进 ~/.codex/.env。第二种：把值保存在秘密存储中，用 op run 启动ChatGPT。它会读取一个包含1Password引用的env文件，通过1Password桌面端认证，解析这些值，并把它们传给ChatGPT。

第一种选择平淡得光荣。第二种让1Password成为唯一持久的秘密存储。两者都是妥协，但都是有用的妥协。我选择了把怪异集中在启动阶段的那种方案。它们是替代方案，不是叠加层。如果你从 ~/.codex/.env 迁移到 op run，请删除明文文件，而不是留下两个凭证来源。

我在macOS上于2026年8月27日测试了这套方案，使用ChatGPT桌面端/Codex应用26.820.71523、Codex CLI 0.150.1和1Password CLI 2.39.0。下文描述的未记录行为可能在后续构建中改变。

可疑地简单的选项：~/.codex/.env

在我测试的ChatGPT/Codex桌面构建上，ChatGPT启动时会加载这个文件：~/.codex/.env。它是一个普通的dotenv文件：

EXAMPLE_API_TOKEN=<实际值>
EXAMPLE_WEBHOOK_SECRET=<实际值>

就是这样。没有sidecar，也没有broker。我用一次全新的ChatGPT启动和一次全新的 codex exec 进程验证了这个行为，后者是同一套本地Codex工具的非交互入口。OpenAI的文档列出了Codex直接支持的环境变量，但没有记录这个文件的自动加载。因此，我把 ~/.codex/.env 视为测试设置下的观察行为，而不是永久的跨平台契约。

保护这个文件，永远不要提交它：