Codex exec Non-Interactive Mode: Wiring Codex Into a CI Automation Pipeline

互動式 Codex 沒辦法跑在 CI 裡——它會停下來等你按核可。
codex exec 就是為此而生：一行指令、無人值守、跑完輸出結果。
這篇給你一套 CI 接法：全自動審批 + 鎖死在工作區的沙箱，放心讓它批次改 code。

[ Log in to see the full prompt ]

## What it is, what problem it solves The interactive Codex you normally use can't just be dropped into CI as-is: mid-run it stops to ask for approval, and there's no one on a CI runner to click confirm — the whole pipeline just hangs. `codex exec` is Codex CLI's non-interactive entry point — one command, it runs to completion and outputs results, without waiting on anyone. It lets repetitive, mechanical, objectively-verifiable tasks — 'fix every lint error,' 'batch-migrate an old API to a new one,' 'backfill type annotations' — run unattended in CI or local scripts. But the trade-off is: since no human is watching, safety has to rest entirely on the sandbox and approval settings. ## Why this source is worth using This piece draws on the community-maintained awesome-codex-cli list (CC0 public domain), which lists `codex exec` as the standard non-interactive / scripting entry point and points to OpenAI's official Codex GitHub Action (which runs codex exec in CI with sandbox controls). That highlights the two keys to wiring into CI: use `codex exec` instead of interactive mode, and use a profile to lock down approvals and sandboxing tight. The key values (approval_policy's never, sandbox_mode's three tiers) are aligned with the official Config Reference, so none of this is made up. ## How to use it (steps) 1. First test locally with `codex exec "..." --profile full_auto` to confirm your task instructions do the right thing and don't overstep. 2. Predefine a `full_auto` profile in config.toml: `approval_policy = "never"` (CI can't wait for approval) plus `sandbox_mode = "workspace-write"` (can only touch the workspace). These two must be paired — never without a restricted sandbox is running it naked on the system. 3. Turn `network_access` off by default, and only flip it to true temporarily when a task genuinely needs to install packages or fetch data. 4. Call `codex exec` in your CI step, phrasing the task as 'a single, objectively verifiable goal,' and add instructions at the end requiring it to 'run the tests, paste the results, list anything needing human attention, and leave no placeholders.' 5. Always route changes through a PR, past tests and human review — never let codex exec push directly to the main branch. ## When to use it When you have a large volume of repetitive, clearly-scoped, mechanically-verifiable code tasks (lint fixes, API migrations, type backfills, batch formatting) you want to automate; or when you want an automatic repair pass to run whenever a PR opens or on a schedule, before a human reviews it. Tasks requiring deep judgment, design trade-offs, or major architectural changes aren't a good fit — those still need interactive human-AI collaboration; full CI automation is asking for trouble there. ## Safety comes first The biggest risk of fully automatic, non-interactive execution is 'no one on hand to hit the brakes.' Three iron rules: when approval_policy is set to never, sandbox_mode must never be danger-full-access (always read-only or workspace-write); network_access is off by default; and the whole task runs on a disposable, isolated runner, with every change gated behind a PR for tests and human review as the final check. Treat codex exec like a diligent intern who makes mistakes — give it exactly enough permission to do the job, never more. 📎 Source: RoggeOhta/awesome-codex-cli (by RoggeOhta, CC0-1.0 public domain) + official OpenAI Codex Action / Config Reference — this piece is a rewritten and reorganized version; see the link above for the original content.