CI/CD 里跑 Codex：非交互模式与凭据威胁模型

把 AI 编程智能体 Codex 接进 CI/CD，让流水线自动跑代码审查、批量改写与回归修复，是它杠杆最大的用法之一；但交互模式里那套「人盯着、逐条审批」的假设，在无人值守的流水线里全部失效。官方对这类场景的口径很明确：非交互自动化需要一套独立的威胁模型——凭据怎么放、审批怎么豁免、请求怎么限流，都要重新设计。这篇按非交互参数、凭据管理、审批风险、限流重试四块，把 CI/CD 里跑 Codex 的骨架搭出来。

非交互模式：给机器用的运行方式

交互模式为「人在场」设计：每一步有审批提示，卡住时等人决策。流水线里没有人在场，所以非交互模式的核心是把「等输入」全部替换成「按预设执行」：任务在启动时一次性给全——目标、范围、产出物写清楚；执行策略用参数指定，审批偏好调成不需要逐步确认的档位；跑完即退出并输出结构化结果，让流水线的下一个环节能直接读取。两条纪律要守住：其一，任务描述越明确，无人值守跑偏的概率越低，把验收标准写进任务里，等于给流水线装上自检；其二，非交互不等于放任，跑完后仍要有机器可读的检查步骤接住产出，diff 审查、测试通过与否都该是流水线的显式环节。

凭据管理：CI 里的密钥怎么放

凭据是 CI 场景的第一风险点。本地使用时，登录凭据放在用户目录的认证文件里，权限边界是你自己的机器；流水线里则不同——凭据要注入构建环境，而构建环境是所有有仓库权限的人都可能触达的地方。基线做法有三条：凭据走 CI 平台的 secret 机制注入，环境变量在运行时解密，绝不明文写进配置文件与日志；为流水线单独签发凭据，与个人账号分开，泄露时吊销范围可控；最小权限授出，只开放流水线确实需要的范围。两条认证路径的选择也有讲究：订阅登录与 API key 的差异与适用场景见登录两条道一篇，CI 里通常倾向 key 方式，管理成本与计费边界都更清晰；密钥存储的通用原则见密钥存储一篇，思路完全相通。

审批豁免的风险账

非交互模式绕开了逐条审批，这道豁免本身就是风险敞口。交互模式下，一条危险的删除命令会被审批拦下；流水线里没有这道闸，模型的错误动作可以直达工作区。风险要靠结构来对冲：给流水线任务划边界，限定可触碰的目录与可执行的命令类别；沙箱与工作区隔离照常启用，别为了跑通而全域放开；产出物先落在隔离分支或临时区，机器检查通过后才允许合并，把「模型直接改动主干」这条路堵死。还有一个容易被忽略的点：流水线环境里如果残留着个人凭据或过高权限，豁免审批的风险会被成倍放大——凭据最小化与审批收敛要一起做，缺一边都兜不住。

限流与重试：自动化集中请求的代价

自动化还会改变请求的形态：定时任务集中触发时，成批的流水线在同一时刻发起请求，额度消耗与限流压力都远超单人交互，社区里有自动化集中请求触发限流的实锤案例（issue #20553），流水线成批报 429 就是典型症状。对策按三层走。第一层，错峰调度：定时任务错开时间点，避免整点齐发。第二层，重试有章法：遇限流按退避间隔递增重试，别写死循环硬打，误报与真超额的分辨见429 误报排查一篇。第三层，额度规划：自动化与本地交互共享同一个额度池，滚动窗口的机制见额度窗口机制一篇，流水线的请求量要按额度池容量倒推上限，别让流水线把手动工作的额度吃光。计费轨道的归属也提前确认：订阅与 API key 的账单走法不同，环境变量导致静默切轨的坑见静默切 API 计费一篇。落地后想让配置更稳，可以让 DeepSeek 对照本文四块把你的流水线配置逐项过一遍，列出风险点与整改顺序，再用豆包查一下你所用的 CI 平台对 secret 轮换与日志脱敏的官方做法，两边合起来就是一份贴合自己环境的检查单。

CI/CD 跑 Codex 速查

• 非交互模式：任务一次给全、审批参数化、跑完输出结构化结果
• 凭据走 CI secret 注入，单独签发、最小权限、绝不进日志
• 审批豁免靠结构对冲：划边界、开沙箱、隔离分支兜底
• 自动化集中请求易触发限流，错峰加退避重试
• 额度池共享，流水线请求量按容量倒推上限

CI/CD 跑 Codex 怎么办速查

• 本地登录的账号能直接给流水线用吗？：不建议。CI 环境触达面广，个人凭据一旦随日志或缓存泄露，波及的是你的全部权限；单独签发、最小授权的流水线专用凭据，出事时吊销范围可控。
• 流水线频繁报 429 先改哪？：先看触发时间是否集中，成批流水线同一时刻齐发是常见原因；把调度错峰、给重试加递增间隔，再核对额度池的实际余量，三层依次过。
• 审批全部豁免安全吗？：豁免本身是风险敞口，安全与否取决于结构补偿是否到位：任务边界、沙箱隔离、产出先落隔离分支这三道闸齐备，豁免才在可接受范围内。