Codex CLI 0.153.2 落地 CI 流水线：从认证失效到沙箱逃逸的三次排查实录
上周有个需求要把 Codex CLI 0.153.2 接入公司内部 GitLab CI，目标是让它在合并请求里自动跑单元测试生成和代码风格修复。按官方文档装完npm i -g @openai/codex@0.153.2后，本地跑codex --version显示0.153.2，一切正常。可一推到 Runner，Job 直接挂在认证阶段，日志只吐出一行Error: Invalid API key。这就开始了长达两天的排查。
环境基线
| 组件 | 版本 | 说明 |
|------|------|------|
| Node.js | 20.18.0 | Runner 镜像自带 |
| npm | 10.8.2 | 随 Node 安装 |
| Codex CLI | 0.153.2 |npm i -g @openai/codex@0.153.2|
| GitLab Runner | 17.3.0 | Docker executor |
| 基础镜像 |node:20.18-slim| Alpine 衍生版 |
本地开发机是 macOS 15.1，Runner 跑在 Kubernetes 集群里的linux/amd64容器。两边 Node 版本一致，但操作系统不同——这点后来成了关键线索。
第一坑：环境变量在 Runner 里「消失」了
第一反应是OPENAI_API_KEY没注入进去。去 GitLab CI/CD Variables 确认过，Variable Type 是Environment variable，Protected 和 Masked 都勾了，Value 也填对了sk-proj-xxxx。可 Job 日志里echo $OPENAI_API_KEY打印出来是空行。
```yaml
.gitlab-ci.yml 片段
codex-review:
image: node:20.18-slim
stage: test
variables:
OPENAI_API_KEY: $CODEX_API_KEY # 这里引用了另一个变量
script:
- echo "Key length: ${#OPENAI_API_KEY}"
- npm i -g @openai/codex@0.153.2
- codex --version
- codex exec "生成 UserService 单元测试" --json
```
在 Runner 容器里跑env | grep OPENAI只有OPENAI_API_KEY=空值。把variables块里的引用改成直接写死$CODEX_API_KEY（去掉大括号），问题解决。GitLab 对变量引用的解析顺序是：先展开variables:里的值，再注入容器环境。如果CODEX_API_KEY本身也是 CI 变量，嵌套引用会在展开阶段失效。
> 这个方案虽然官方文档里写得清清楚楚，但在我们场景下反而更糟——因为CODEX_API_KEY是在 Group 级别定义的，Project 级别的variables:块拿不到上层变量。最后改用resource_group配合trigger传参才彻底绕开。
第二坑：沙箱模式下无法读取.git目录
认证通了，跑codex exec "重构 UserController" --sandbox read-only报错：
```
Error: EACCES: permission denied, open '/builds/group/project/.git/config'
```
Codex 0.153.2 引入了--sandbox参数，三种模式：read-only、workspace-write、danger-full-access。文档说read-only允许读取工作目录下所有文件，但 Runner 容器里的工作目录/builds/group/project属于root:root，权限drwxr-xr-x，而 Codex 进程跑在node用户（UID 1000）下。.git目录权限是drwxr-x---，组是root，node用户既不在组里也没 others 读权限。
```dockerfile
修复方案：自定义镜像预置权限
FROM node:20.18-slim
RUN groupadd -g 1000 node && \
usermod -a -G root node && \
chmod 755 /builds 2>/dev/null || true
USER node
```
重新构建镜像推到 Registry，CI 配置里image: registry.internal/codex-runner:20.18。再跑一次，read-only模式能正常读.git了。但这引出第三个问题——沙箱写模式下生成的文件宿主机看不见。
第三坑：workspace-write生成文件 UID/GID 不匹配
需求要求 Codex 在沙箱里直接改代码、写测试文件。改用--sandbox workspace-write后，Job 成功，但合并请求里看不到任何变更。进 Runner 容器ls -la发现新生成的UserControllerTest.java属于1000:1000，而 GitLab Runner 默认用root提交变更。Git 里配置的user.email和user.name是 Runner 的，但文件所有者是node用户，导致git add时出现warning: unable to access '...': Permission denied。
```bash
CI 脚本里补齐权限修正
- codex exec "为 UserService 生成单元测试" --sandbox workspace-write --json
- find . -type f -newer .git/index -exec chown root:root {} \;
- git config --global user.email "ci@company.com"
- git config --global user.name "GitLab CI"
- git add -A
- git commit -m "chore: codex auto-generated tests [skip ci]" || true
- git push origin HEAD:$CI_MERGE_REQUEST_TARGET_BRANCH_NAME
```
find . -newer .git/index只改 Codex 本次运行新增/修改的文件，避免把整个工作目录 chown 一遍拖慢流水线。|| true防止无变更时 commit 失败把 Job 标红。
验证与回归测试
跑通后补了三组回归用例：
| 场景 | 预期 | 实测结果 |
|------|------|----------|
| MR 触发，Codex 生成测试覆盖率 < 60% | Job 通过，MR 自动更新 | ✅ 通过 |
| 代码冲突导致git push失败 | Job 失败并报警 | ✅ 失败退出码 1 |
|OPENAI_API_KEY过期 | Job 失败，日志不泄露 Key | ✅ 仅显示Error: 401 Unauthorized|
关键验证命令：
```bash
本地模拟 Runner 环境
docker run --rm -it \
-v $(pwd):/builds/project \
-w /builds/project \
-e OPENAI_API_KEY=$OPENAI_API_KEY \
registry.internal/codex-runner:20.18 \
bash -c "codex exec '生成测试' --sandbox workspace-write --json"
```
用--json输出方便 CI 解析，配合jq提取files_changed字段做门禁判断。
避坑清单
- 变量嵌套引用别信 GitLab 文档的展开顺序，直接在 CI 里
export OPENAI_API_KEY=$CODEX_API_KEY再跑 Codex 最稳 - 沙箱权限模型是容器级的，不是项目级的——镜像里必须把工作目录权限、用户组处理好
- 生成文件的 UID/GID 必须与 Git 提交者一致，否则
git add会静默失败只报 warning - Codex 0.153.2 的
--json输出格式里exit_code字段在沙箱报错时为null，要改判断stderr非空 - 别在生产流水线直接跑
danger-full-access，哪怕内网也要走workspace-write+ 显式chown
总结
Codex CLI 0.153.2 本身功能没毛病，核心矛盾全在「容器环境里的用户身份、文件权限、GitLab 变量展开顺序」这三个工程细节上。把这三个坑填平，流水线从「跑不通」变成「日均处理 40+ MR，测试覆盖率提升 18%」，才算真正落地。
#后端 #Java #SpringBoot #CI/CD #CodexCLI
你在实际项目中有遇到类似问题吗？欢迎在评论区分享你的经验和解决方案。
