Codex CLI怎麼用？Permissions、Sandbox、AGENTS.md、Review與非互動模式

Codex CLI怎麼用？Permissions、Sandbox、AGENTS.md、Review與非互動模式

先講結論：Codex CLI可在本機Repository讀取、修改與執行命令。本文整理安裝、登入、/init、/permissions、/model、/review、AGENTS.md、Sandbox、Git Branch、MCP、Skills、非互動模式、CI與安全回退流程。

Codex CLI怎麼用？Permissions、Sandbox、AGENTS.md、Review與非互動模式在講什麼？ Codex CLI可在本機Repository讀取、修改與執行命令。本文整理安裝、登入、/init、/permissions、/model、/review、AGENTS.md、Sandbox、Git Branch、MCP、Skills、非互動模式、CI與安全回退流程。

先記住哪個結論？ 核心是把「Codex CLI怎麼用？Permissions、Sandbox、AGENTS.md、Review與非互動模式」放回完整脈絡，區分已知資訊、背景與可延伸的判斷。

文中整理了哪些重點？ 文章依序整理：Codex CLI可在本機Repository讀取、修改與執行命令。本文整理安裝、登入、/init、/permissions、/model、/review、AGENTS.md、Sandbox、Git Branch、MCP、Skills、非互動模式、CI與安全回退流程。，並補充相關背景、影響與讀者可查證的線索。

讀者最容易忽略什麼？ 不要只看標題；請同時確認時間、人物、作品或事件名稱，以及資訊的原始來源。

這個主題和台灣讀者有何關係？ 對台灣讀者而言，清楚的中文脈絡、關鍵字與可延伸閱讀入口，能讓後續查證更有效率。

哪些資訊需要再核對？ 涉及日期、名單、票價、健康、政策、交通或產品規格時，仍應以文章列出的一手來源與最新公告為準。

如果只看一段，建議看哪裡？ 可先讀這個答案區與文章開頭，再依需求回到正文的背景、分析與常見問題。

這篇內容適合誰？ 適合想快速掌握「Codex CLI怎麼用 Permissions Sandbox AGENTS.m…」並需要延伸閱讀入口的讀者。

一句話總結？ 一句話：Codex CLI可在本機Repository讀取、修改與執行命令。本文整理安裝、登入、/init、/permissions、/model、/review、AGENTS.md、Sandbox、Git Branch、MCP、Skills、非互動模式、CI與安全回退流程。

Codex CLI是OpenAI提供的本機Coding Agent，可在選定Repository內讀取檔案、提出修改、執行命令和協助Review。安全使用的重點不在讓它取得最大權限，而在先讀取Repository Instructions、使用小型Branch、限制Sandbox，再以Tests和Diff確認每一個變更。

互動模式適合探索與逐步修正；非互動模式適合已經穩定、可重複且有Exit Code的自動化。尚未定義Acceptance、Rollback和Permission的任務，不應直接接進背景或CI流程。

• 在Repository Root啟動前先建立Git Branch或Worktree。
• /init可協助建立AGENTS.md，保存專案命令與規則。
• /permissions用來查看或調整Agent可執行範圍。
• /model用於選擇模型與推理設定；高推理不代表可以跳過測試。
• /review適合在合併前檢查本地變更。
• Sandbox應從Read-only或Workspace Write起步，Network和高風險Action另行批准。
• MCP、Skills與Plugins會擴大能力，也擴大資料和供應鏈邊界。
• 非互動模式必須有固定輸入、結構化輸出、Timeout與Exit Code。

Codex CLI 的權限、沙盒與交付

Codex CLI 怎麼用，核心在 Permissions、Sandbox、AGENTS.md、Review、Git 與非互動模式如何形成安全交付流程。文章把命令列入口、專案規則、檔案權限、差異審查與自動化執行分開。

CLI 工作流如何保留控制

• Permissions：限制代理能讀、寫、執行與連線的範圍。
• Sandbox：隔離檔案／程序／網路風險，必要時才提升權限。
• AGENTS.md：保存專案規則與測試指令。
• Review／Git：以 diff、測試、commit 與可回滾歷史完成交付；非互動模式也要有明確停止條件。

本文以「Codex CLI 的權限、沙盒與交付」為主線，補回人物、作品、制度、技術、場景與它們之間的關係，讓讀者能從具名實體一路追到實際流程與文化語境。

安全起始流程

new branch or worktree
→ read AGENTS.md and repository docs
→ explain plan
→ make a small change
→ run focused tests
→ review diff
→ human approval
→ merge

1. 確認Repository乾淨且可回退。
2. 建立獨立Branch或Worktree。
3. 要求Codex先解釋架構與計畫。
4. 限制第一輪File和Scope。
5. 執行相關Tests與Lint。
6. 檢查Diff和未預期變更。
7. 由人決定是否繼續或合併。

安裝、登入與Project Root

• 安裝方式與版本以OpenAI官方Codex CLI文件為準。
• 使用ChatGPT帳戶或支援的API設定登入。
• 從正確Repository Root啟動，避免讀取上層無關檔案。
• 先查看版本、Status與目前Permission。
• 企業環境依管理員Policy和Managed Configuration執行。

不要從Home Directory或包含多個客戶專案的父目錄直接啟動Agent。作用目錄本身就是安全邊界的一部分。

互動模式與非互動模式

模式	適合	主要控制
互動TUI	探索、Debug、重構和討論	逐步批准與Diff Review
非互動Exec	固定檢查、批次任務和Automation	Timeout、Exit Code、結構化輸出
Cloud Task	長任務和隔離環境	Environment、Branch和Artifact
CI／GitHub Action	可重複品質或安全工作	Token、權限和Required Checks

非互動模式不適合需求仍在變動的工作。先在互動模式建立穩定Task Contract和驗證方式，再自動化。

常用Slash Commands

Command	用途
/init	協助建立AGENTS.md或專案指引
/status	查看Session、Model和環境狀態
/permissions	查看或調整執行權限
/model	選擇模型和推理設定
/review	檢查本地Diff或變更

CLI功能會持續更新，實際Command與參數應以目前安裝版本和官方文件為準。

AGENTS.md

# AGENTS.md

## Commands
- install: pnpm install
- test: pnpm test
- lint: pnpm lint
- build: pnpm build

## Rules
- Never edit generated files.
- Database migrations require approval.
- New API routes require auth tests.
- Do not read or print .env values.

## Definition of done
- Focused tests pass.
- Lint and typecheck pass.
- Summarize changed files and risks.

• 保存長期有效命令和規則。
• 使用可執行指令，不寫模糊形容詞。
• 標示禁止修改的目錄和高風險操作。
• 加入Definition of Done。
• 子目錄可使用更接近檔案的AGENTS.md細化規則。

完整Repository Context可閱讀AI編程協作怎麼避免上下文斷裂？。

Permissions和Sandbox

模式	適合	風險
Read-only	理解Code和提出Plan	低
Workspace Write	修改目前Repository	需Git和Tests
Network Access	文件、Package和API	資料外傳與供應鏈
Full Access	極少數受控環境	高，不宜作為Default

• 只開放完成Task所需File和Command。
• Production Credential不進CLI Session。
• Package Install和外部下載需要Review。
• 刪除、Deploy和Database Action另設人工Gate。
• Permission提升應有期限，完成後降回。

Git Branch與Worktree

• 每個Task使用獨立Branch。
• 平行Agent使用不同Worktree，避免同檔衝突。
• Protected Branch不允許直接Push。
• Commit包含Task和Agent參與資訊。
• 大型變更拆成Small PR。
• 未採用Branch按Policy清理。

Review工作流

1. 確認Task與Acceptance。
2. 查看Changed Files和Diff Summary。
3. 檢查不必要Dependency或Formatting。
4. 執行Tests、Type Check與Security Scan。
5. 要求Codex解釋Risk與Rollback。
6. 由Code Owner完成最終Review。

/review可作第一輪檢查，不取代Domain、Security和Architecture Owner。

MCP、Skills、Plugins與Hooks

能力	用途	檢查
MCP	連接文件、Issue、資料和Tool	Server身份、Scope和Log
Skills	保存可重複工作方法	Version、Source和Acceptance
Plugins	擴充整合或工作流	Publisher和Supply Chain
Hooks	在事件前後執行檢查	副作用、Timeout和Failure

每增加一個Integration，都會增加新的Trust Boundary。未核准MCP和Plugin不應連接正式Repository或帳號。

非互動模式的輸入與輸出

automation_contract:
  task: dependency-audit
  input: repository commit
  output: findings.json
  timeout: 20m
  network: allowlisted registries only
  write: none
  exit_codes:
    0: no blocking issue
    2: findings require review
    3: execution failure

• 固定Base Commit和Working Directory。
• 輸出JSON或Artifact，不依賴自然語言解析。
• 設定Timeout、Retry和最大成本。
• 錯誤和Partial Success使用不同Exit Code。
• 不可在CI中自動合併未Review的Code。

Local、Cloud與GitHub Action分工

環境	適合
Local CLI	即時協作、Debug和本機工具
Cloud Task	隔離長任務、可留下Branch和Artifact
GitHub Action	固定Review、Migration和品質流程
IDE／App	視覺化Task、Diff和多工作區

不適合直接自動化的任務

• 需求未定義的重大架構。
• 沒有Backup的Database Migration。
• Production Deploy與Secret修改。
• 付款、權限和客戶資料變更。
• 沒有Test和Owner的大型重構。
• 不清楚License的Dependency導入。

常見問題

Codex CLI會直接修改專案嗎？

在允許寫入的Permission下可以。應使用Branch、Workspace Sandbox、Tests和Diff Review控制。

初學者應該開Full Access嗎？

不應。先從Read-only或Workspace Write開始，高風險命令逐次確認。

何時適合用非互動模式？

任務已穩定、輸入輸出可結構化、Failure和Exit Code明確，且不需要臨時人類判斷時。

如果要先建立 Codex 的產品全貌，再深入 CLI 的 Permissions、Sandbox 與非互動流程，可先閱讀 OpenAI Codex App、Cloud Tasks、CLI、AGENTS.md 與 Sandbox 指南；本頁則專注在終端機與 repository 內的執行控制，兩頁不重複承諾模型能力或帳戶資格。

官方資料

• OpenAI Codex CLI文件
• OpenAI Codex開發文件

Codex CLI的價值，是讓Coding Agent進入Repository、Terminal和Git。安全邊界則來自AGENTS.md、Permissions、Sandbox、Tests和Human Review；自動化只能建立在這些條件已經穩定之後。

YOLO_DEPTH_IMAGE_37161_20260817

Codex CLI 的定位：把程式工作留在可觀測的終端流程

Codex CLI 不是只在終端機裡聊天的問答工具。官方文件把它定位為可以在 terminal 內檢查程式碼、修改檔案、執行命令，並把重複工作組合進腳本與 CI 的 coding agent。這個定位有兩個重點：它能動到本機 repository，也能把動作變成可重複的流程；因此真正的使用問題不是「它會不會寫程式」，而是「哪些目錄、哪些命令、哪些權限可以讓它在這一次任務裡使用」。

開始之前先把任務分成四個階段：理解、修改、驗證、交付。理解階段只要求它讀取結構、規則與相關檔案；修改階段限制在明確範圍；驗證階段執行已知測試並保存結果；交付階段由人檢查 diff、狀態與回退點。這種切法可以把「能做到」和「現在應該做」分開，避免一開始就把終端權限開到最大。

第一次進入專案：先確認目錄、Git 與專案規則

不要從任意目錄直接啟動大型任務。先進入正確 repository，確認 git status、目前分支、未提交修改與遠端狀態，再讓 Codex CLI 讀取 README、測試命令、建置說明與 AGENTS.md。若工作樹本來就有使用者修改，先把它們列出並在任務中標記為不可碰觸；不要讓 agent 把既有差異誤當成自己需要修正的 bug。

官方 CLI 介面提供 /init 建立 AGENTS.md 的入口。這個檔案的價值不在於寫一篇長手冊，而在於把代理每次都需要知道的專案事實固定下來：可以使用的 package manager、測試與 lint 命令、禁止修改的路徑、資料庫或部署限制、完成前必跑的檢查，以及遇到不確定時要停止的條件。規則必須短、可驗證、與專案現況一致；過期的 AGENTS.md 會比沒有規則更危險，因為它會給 agent 一個錯誤的信心。

/status、/model、/permissions 與 /review 各自解決什麼問題？

/status 用來查看目前 session 設定；它適合在任務開始、中途變更權限或準備交付前重新確認。不要只看畫面上顯示的模型名稱，還要知道目前工作目錄、sandbox、可寫範圍與是否存在未完成的上下文。清楚的狀態紀錄能幫助你在回顧時回答「這個 diff 是在哪個設定下產生的」。

/model 用來選擇模型與 reasoning effort。模型選擇應配合任務風險與驗收成本：讀取結構、整理文件和小型機械修改不一定需要最昂貴設定；跨模組重構、疑難錯誤或需要大量推理的任務，則應把成本與品質一起測。不要把模型名稱直接當成完成保證，真正的品質仍由測試、diff、review 與公開或部署後 read-back 決定。

/permissions 是權限邊界的入口。官方文件強調，使用者可以選擇 Codex 何時能編輯檔案或執行命令而不再詢問，並檢查目前 sandbox 與可寫根目錄。權限不是方便程度的二元開關，而是每一個任務的風險設定；讀取、修改、網路與外部服務應該分開思考。

/review 用來檢查變更與找問題。它不應被當成最後一道唯一防線，因為 review 仍然需要正確的測試、規格與安全上下文；但在提交或交給另一位工程師前，讓 CLI 重新檢查 diff、未完成 TODO、錯誤處理、測試缺口與不必要的檔案，是很便宜的第二次視角。

Sandbox 與 approval：兩個控制面不要混為一談

Sandbox 控制的是模型產生命令能接觸哪些資源；approval 則控制哪些動作需要人確認。只開 sandbox 不代表所有命令都安全，只開 approval 也不代表命令能在正確範圍內執行。穩妥的做法是先選最小可用 sandbox，再對寫檔、安裝套件、網路、刪除、資料庫與部署等動作保留核准點。

官方 CLI reference 列出 --sandbox 的 read-only、workspace-write 與 danger-full-access 選項；也明確提醒繞過 approval 與 sandbox 的選項具有危險性，只應在隔離 runner 裡使用。對日常 repository 工作，通常先從 read-only 偵察，再切到 workspace-write 做受限修改；只有在明確隔離、可回收且經過審核的環境，才討論更寬的權限。

權限設定還要配合 secrets。即使 sandbox 允許執行測試，也不表示應該把 production token、SSH key、雲端憑證或客戶資料放在 agent 可見環境。測試環境使用最小權限與假資料，並在任務結束後檢查 shell history、產物、log 與未追蹤檔案是否意外包含秘密。

AGENTS.md 怎麼寫才不會變成形式文件？

一份有效的 AGENTS.md 應該能被轉成檢查清單，而不是只描述團隊文化。可以用以下結構：專案目的與目錄邊界、啟動與安裝命令、單元測試與整合測試、格式化與 lint、禁止修改的檔案、資料與秘密規則、提交前檢查、遇到外部狀態或不確定時的停止條件。每條規則最好能對應一個命令、檔案路徑或明確的人工作業。

如果 repository 有多層 AGENTS.md，應該讓更接近目前檔案的規則只補充局部差異，不要在子目錄重新複製整份全域規則。規則之間衝突時，先停下來釐清，而不是讓 agent 自行挑選最方便的一條。更新 AGENTS.md 後，也要在 review 中檢查它是否會影響既有自動化；一條新的「可自動執行」規則，可能會改變 CI 對整個 repository 的權限與成本。

Git 分支與 checkpoint：讓 agent 的修改可以回到已知狀態

官方 CLI quickstart 建議在任務前後建立 Git checkpoint，以便回退。實務上可在開始前保存乾淨基準或明確記錄既有 dirty state，再為一個任務建立獨立分支；agent 每完成一個可驗證階段，就保存一次小而清楚的 commit 或 patch。這不是要求每一個檔案都立刻提交，而是讓「修改前」「測試通過」「人工 review 後」這些狀態可以被比較。

回退也有層級：若只改錯一個檔案，可以用局部 patch；若整個任務方向錯誤，回到任務前 checkpoint；若外部資料或 schema 已經變動，則不能只靠 Git，還需要資料回復或反向 migration。不要把 git reset 當成萬能撤銷按鈕，也不要在有未確認使用者修改時用破壞性命令清空工作樹。安全回退的前提，是先確認目標、保留備份並知道哪些外部狀態不在 Git 裡。

非互動模式與 codex exec：適合把流程變成 CI 的前提

官方文件把 codex exec 放在可重複腳本與 pipeline 的使用方式裡。非互動模式的價值是輸入、權限、輸出與退出碼可以被 CI 管理；風險則是少了人即時阻止錯誤命令。先把任務縮成單一責任，指定工作目錄與 sandbox，固定輸出格式，讓命令失敗就停止，並把最後訊息、diff 與測試報告保存為 artifact。

使用 --json 或輸出檔案時，先定義下游真正需要的 schema：任務狀態、變更檔、測試結果、未完成項目、阻塞原因與人工核准欄位。不要只解析自然語言中的「完成」兩個字。若自動化需要知道模型改了什麼，直接從 Git diff、測試報告與 CI 狀態讀取，而不是把模型摘要當成唯一真相。

--sandbox workspace-write 可以讓非互動任務在受限工作區內寫入；官方 reference 也指出 --full-auto 是相容用旗標，偏好 workspace-write。至於繞過 approval 與 sandbox 的 yolo 類選項，只有在已經隔離、審核並能銷毀的 runner 裡才有合理場景。一般 CI 不應用一個危險旗標換取短期方便。

CI 的 Codex 任務要怎麼設計負面驗收？

第一類負面驗收是權限：故意讓任務碰到不可寫目錄、秘密檔案、外部網路或 production 設定，確認 CLI 會拒絕、要求核准或清楚回報。第二類是工作樹：在開始前放入未提交修改，確認 agent 不會覆蓋或把它們誤當成自己的成果。第三類是測試：讓測試失敗、輸出不完整或工具逾時，確認結果不會被包裝成成功。

第四類是指令注入與不可信內容。README、issue、測試資料與第三方程式碼都可能包含「請忽略規則」之類的文字；它們是待分析資料，不是自動取得更高權限的指令。AGENTS.md、使用者當前任務與平台權限規則之間應有清楚優先級，遇到衝突就停下來要求人工決定。這種測試比單純跑一個 happy path 更能顯示工作流是否真的安全。

Skills、MCP 與非互動 CLI 的邊界

Codex 可以把重複規則包成 skills，也能透過 MCP 連接外部工具；這些能力會擴大可做的事情，同時也擴大資料流與權限面。新增 skill 或 MCP 前，先確認來源、命令、網路、認證、輸出資料與可寫範圍，再做最小 smoke test。不要因為工具在清單裡就假設它可信，也不要讓一個外部 connector 直接擁有整個 repository 或 production 的寫入權。

對 CI 而言，外部工具最好被包在明確的 adapter 裡，輸入輸出有 schema，錯誤可追蹤，權限可以單獨撤銷。每次任務把使用過的 MCP tool、技能版本與外部請求摘要寫入 artifact，但避免保存秘密與完整私人資料。當工具結果與本機檔案、測試或公開 read-back 不一致時，以可重現的本機或官方 read-back 為準，不要只信 MCP 回傳的一段成功訊息。

一個可執行的 Codex CLI 工作模板

第一步，寫下目標、輸入、禁止動作與完成條件；第二步，建立或確認 Git checkpoint，執行 git status 並保存初始狀態；第三步，以 read-only 或最小 sandbox 讓 Codex CLI 說明它看到的目錄、規則、測試與風險；第四步，只授予工作樹寫入，要求小範圍修改；第五步，執行測試、lint、build、security scan 與 diff review；第六步，把結果整理成可審查 artifact；第七步，由人決定合併、回退、補測試或停止。

如果任務中途需要擴大權限，先說明原因與替代方案，再單獨核准，不要讓「上一個命令已經允許」變成永久授權。若 agent 開始修改不在目標範圍的檔案、反覆重試同一失敗命令、讀取不必要的秘密或無法說明下一步，就停止該回合，保存現況並重新切小任務。能夠安全停止，是 coding agent 成熟工作流的一部分。

Codex CLI 的完成定義：不是輸出漂亮，而是證據閉環

一篇可靠的 Codex CLI 使用紀錄，應該能回答：使用了哪個版本與模型、在哪個 repository 與分支、採用什麼 sandbox 與 permission、讀取了哪些規則、修改了哪些檔案、執行了哪些命令、測試與 review 是否通過、有哪些未驗證項目、如何回退，以及誰最後核准。這些資訊比一張看起來很順的終端截圖更有價值，因為它們能讓另一位工程師重跑或反駁結果。

Codex CLI 可以把理解、修改、測試與 review 放進同一個終端工作流，但它不會自動替團隊承擔規格、資安、法遵、部署與資料回復責任。當權限、外部狀態或需求出現真正不確定時，最好的下一步不是繼續產生更多命令，而是留下證據、縮小範圍並請人決定。把這條界線保留下來，CLI 才會從一次性的自動補程式，變成可以長期維護的工程工具。

官方 OpenAI 文件與本文更新界線

本文關於 Codex CLI 的終端定位、/init、/status、/permissions、/model、/review、Git checkpoint、skills、MCP 與 codex exec，參考 OpenAI Codex CLI 官方文件；命令旗標、sandbox、JSON 輸出、--model、--sandbox、--full-auto 與非互動參數，參考 OpenAI Codex CLI reference；官方頁面目前也提供對應的 ChatGPT Learn Codex CLI 說明。

本文的權限分層、負面驗收、CI artifact 與回退流程是 YOLO LAB 的工程編輯整理，不代表 OpenAI 對每個 repository 或部署環境的保證。安裝命令、模型、權限預設值、旗標、產品可用性與安全建議可能更新；執行前請重新查看官方文件與本機 codex --help，並以實際版本與組織政策為準。

增量：Codex CLI 的重點，不是讓 Agent 自動跑完，而是把自動化放在可控的沙盒裡

Permissions 與 Sandbox 應分開理解：Sandbox 限制程式實際能碰到的檔案、網路與程序；Permission approval 則決定哪些需要人確認。兩者一起設計，才能讓低風險讀取順暢，也讓高風險寫入有清楚的升級點。

AGENTS.md 提供專案上下文，Review 則檢查變更是否符合意圖；它們不能互相取代。文件寫得再好，仍要看 diff、測試與副作用；沙盒再安全，也不能替團隊決定一個 patch 是否真的該合併。

官方 Codex CLI 入門文件可作為基本設定與模式的核對入口：OpenAI Codex CLI – Getting Started。版本更新後，旗標、權限模式與支援平台可能變動，操作指南應附上查證日期與實際命令。

一個可靠的 CLI 流程是：先讀規則與狀態，再提出計畫；執行最小 patch；跑快速測試；展示差異與風險；最後才由人決定是否合併。自動化的終點不是取消審查，而是讓審查更聚焦。