--- slug: codex-exec-noninteractive-automation title: Codex exec：給腳本、CI 和自動化的非互動模式 status: published excerpt: 拆解 OpenAI Codex 的 `codex exec` 在做什麼、適合什麼場景、為什麼很多人很少真的拿它上線。 category: AI Tools tags: [codex, automation, cli, ci, sandbox] author: Seer author_role: Author read_time: 7 min cover: "/static/codex-exec-noninteractive-automation-cover.png" closing_note: "自動化的最高境界，是讓 AI 在深夜默默工作，而你隔天早上醒來，只看見完美的 JSON 輸出。" published_at: "2026-05-31T00:00:00Z" updated_at: "2026-07-01T15:54:39Z" --- 上禮拜五下班前，主管要我寫一個腳本，在每天半夜自動去撈 GitHub 上的 Git diff，並用 AI 產生一份 Release note 寄給全團隊。我第一時間想到，如果用一般的 AI 對話視窗，我得每天手動複製貼上，這顯然不切實際。為了解決這種「不需要人類在線回對話」的自動化流水線任務，OpenAI Codex 其實內建了一個叫做 `codex exec` 的非互動式（Non-interactive）執行模式。 這篇文是從我前一篇文章 [Claude Code Dynamic Workflows 與 Windsurf / Codex 的差別](/claude-code-dynamic-workflows-windsurf-codex/) 中，單獨把 `codex exec` 的實戰心得抽出來整理的筆記。 官方文件的描述非常偏向工程實務：進度狀態一律印在 `stderr`，而最終的執行結果只會寫進 `stdout`，並且支援 schema 驗證以確保能輸出百分之百合規的結構化 JSON 資料。為了安全起見，它預設是跑在一個唯讀的沙盒（read-only sandbox）裡，只有在你明確授權時，才會放開成 `workspace-write` 權限來允許修改專案檔案。 官方文件參考：[Non-interactive mode](https://developers.openai.com/codex/noninteractive)、[Config reference](https://developers.openai.com/codex/config-reference)、[Security](https://developers.openai.com/codex/security)。 --- ## 本質上，它就是 CI/CD Pipeline 裡的一個 Job 把 `codex exec` 定位成一個「無頭（Headless）CLI 工具」比較精確：給它輸入，在沙盒裡運算，然後吐出機器看得懂的輸出。它不是拿來跟你聊天的，它更適合扮演 CI/CD 流程中的一個步驟、排程工作（Cron job）中的一個 action，或者是發版（release）流程中的變更摘要器。 常見的實戰情境包含： - 自動去抓 Git diff 並摘要這次的變更風險。 - 撈出 PR 的代碼，在合併前自動做 pre-merge 的防禦性檢查。 - 每天半夜排程掃描 codebase，回傳結構化的漏洞分析結果。 這些任務的共同點在於「輸入與輸出非常明確，不需要人類在終端機前一來一回地跟它打字」。 --- ## 哪些情境適合用它？ 如果你希望 AI 成為你既有自動化工作流中的一個樂高積木，用 `codex exec` 就對了。例如在 GitHub Action 裡面，當有人發 PR 時，自動跑這個指令去撈 schema，並確認有沒有違反專案規範。 結構化輸出是它最強大的賣點。官方原生支援 `--json`、`--output-schema` 以及 `-o / --output-last-message` 參數。當你需要把 AI 的回應對接到下游的其他系統或資料庫時，拿到乾淨的 JSON 欄位，比在那裡通靈去 parse 亂吐的 markdown 文字要實際太多了。 相反地，如果你現在正對著一堆 bug 沒頭緒，想要有人幫你出主意，或是只想改一個錯字、修一行 import，那還是老老實實用互動模式（interactive mode）的對話框比較省事。`codex exec` 的價值只存在於「多工具串聯」的自動化管道中。 --- ## 為什麼它在社群上的討論度不高？ 我自己觀察，主要有兩個原因： ### 1. 概念不夠直覺 大多數人第一次用 Codex 或是 AI coding 助手時，都是在 IDE 或 Terminal 裡面一問一答。那種體感像是「身邊帶了一個小助手」。而 `codex exec` 需要你有 pipeline 思維：你得先想好輸入的資料要怎麼 pipeline 進去、輸出要由誰來接、sandbox 的安全等級該怎麼開、要用什麼 JSON Schema 來卡關。這對一般只想寫 code 的人來說，門檻稍微高了一點。 ### 2. 毫無視覺展示效果 互動式 Agent 在操作時會一直轉圈圈、秀出修改了哪些檔案，非常適合錄影分享或發 Twitter。但 `codex exec` 默默在背景跑，成功了就吐出一串 JSON，失敗了就回傳 exit code，低調到幾乎沒有存在感。 --- ## 它跟 Claude Code、Windsurf 的差異在哪？ - **`codex exec` vs Claude Code (`claude -p`)**：兩者其實很接近，都偏向腳本化與非互動模式。但 Claude Code 最近的大改版（Dynamic Workflows）更專注在如何讓 Agent 自己動態寫出 JS 去協調複數子代理；而 `codex exec` 則依然保持單純，適合作為 CI/CD pipeline 裡被呼叫的那個穩定元件。 - **`codex exec` vs Windsurf Workflows**：Windsurf 走的是完全不同的路線，它的 workflow 是 Markdown 格式的 SOP，要在 IDE 裡由開發者手動按鈕去觸發。 --- ## 我目前的實戰做法與收尾 選擇很簡單： - **需要人機協作、邊問邊改**：開互動式 Codex 視窗。 - **需要排程自動化、串接 CI/CD、寫腳本分析**：用 `codex exec`。 這工具雖然很少出現在各大技術論壇的熱門貼文裡，但它確實把大語言模型包裝成了一個合格的、可控的工程元件。對於需要把 AI 塞進工作流管道裡的開發者來說，這遠比再多一個對話視窗實用得多。