Codex 的「工作區寫入」到底代表什麼？

如果你開始使用 Codex 進行程式開發，可能會在權限設定中看到：

sandbox_mode = "workspace-write"

從中文字面來看，「工作區寫入」很容易被理解成：

讓 Codex 可以幫我新增檔案、修改程式碼。

但實際上，它代表的是更完整的「工作區檔案修改權限」。

OpenAI 官方文件將 workspace-write 描述為 Codex 可以在工作區中讀取檔案、進行編輯並執行一般專案命令；Sandbox 的目的，就是界定 AI Agent 可以自行活動的範圍。

因此對一般工作區檔案來說，除了：

• 讀取檔案
• 新增檔案
• 修改檔案
• 重新命名檔案

也要把：

• 刪除檔案

納入風險考量。

換句話說：

workspace-write 不是只允許 Codex「寫程式」，而是把指定工作區的檔案變更能力交給 Agent。

workspace-write 可以刪除檔案嗎？

答案可以直接說：

可以，工作區內一般可寫入的檔案可能被刪除。

假設你的專案目錄是：

D:\Projects\my-app\
├─ src\
│  ├─ app.py
│  └─ old.py
├─ tests\
└─ README.md

而 D:\Projects\my-app\ 就是 Codex 目前的 Workspace。

當你設定：

sandbox_mode = "workspace-write"

Codex 就可以在 Sandbox 允許的工作區範圍中進行檔案修改。OpenAI 也說明，workspace-write 可以讓 Codex 在目前工作區及指定的 writable roots 中進行修改。

因此，如果 Agent 判斷：

old.py

已經不需要，它可能在執行重構或清理專案時將這個檔案刪除。

但不是工作區裡「所有東西」都一定能刪

這裡有一個很值得注意的細節。

OpenAI 目前的 Codex 文件特別指出，在預設 workspace-write Sandbox 中，即使位於 writable root 裡，部分特殊路徑仍然會被保護成唯讀，例如：

.git/
.agents/
.codex/

而且這些保護是遞迴套用的。

也就是說，不能簡化成：

Workspace 裡所有檔案都可以任意刪除。

比較精確的說法應該是：

Workspace-write 允許 Codex 修改工作區內的一般可寫入檔案，但部分受保護路徑仍可能維持唯讀。

這也是 Sandbox 真正的價值：它不是單純的「開／關權限」，而是在不同目錄之間建立邊界。

最容易誤會的是：on-request 不代表「刪除前一定會問」

很多人會把下面這兩個設定搭配使用：

approval_policy = "on-request"
sandbox_mode = "workspace-write"

然後直覺認為：

「既然我選了依請求，Codex 如果要刪檔案，應該會先問我吧？」

這其實不一定。

關鍵就在於：

Sandbox 與 Approval Policy 是兩個不同的控制機制。

OpenAI 官方對兩者的區分相當明確：

Sandbox 負責定義 Agent 可以自行活動的技術邊界；Approval Policy 則決定 Agent 需要跨越這個邊界時，何時必須停下來要求核准。

Sandbox 決定「能做什麼」

例如：

sandbox_mode = "workspace-write"

代表 Codex 已經取得在工作區內進行一定程度修改的能力。

可以簡化成：

Codex 準備執行操作
        ↓
是否位於 Sandbox 已允許的範圍？
        ↓
       是
        ↓
     可以執行

OpenAI 官方也說明，Agent 在 Sandbox 已允許的範圍內進行例行操作時，可以繼續工作，不需要因每個低風險命令停下來確認。

Approval Policy 決定「撞到邊界後怎麼辦」

再來看：

approval_policy = "on-request"

它真正控制的是：

Codex 需要超越目前 Sandbox 邊界時，要不要提出額外核准要求。

例如：

Codex 執行任務
        ↓
Sandbox 是否允許？
     ↙       ↘
   允許      不允許
    ↓          ↓
繼續執行    要求核准

OpenAI 對 workspace-write + on-request 的官方說明也是：Codex 可以在 Workspace 內讀取、編輯檔案並執行命令，而編輯 Workspace 外部內容或進行其他受限操作時，才需要額外核准。

因此：

on-request 不能理解成「所有刪除檔案操作都會先問我」。

如果刪除的對象本來就位於 Sandbox 已允許修改的範圍內，就不應預設一定會出現核准視窗。

workspace-write + on-request 該怎麼理解？

我認為最容易理解的方法是把它翻譯成一句話：

工作區裡讓 Codex 自己工作，需要突破工作區權限時再問我。

OpenAI 目前也會針對版本控制中的專案推薦類似的 Auto 設定，也就是：

workspace-write
+
on-request

讓 Codex 可以讀取檔案、修改程式並執行專案命令，同時保留 Sandbox 邊界。

這種設定很適合 Agentic Coding，因為 AI 可以自行完成：

分析需求
↓
讀取程式碼
↓
修改程式
↓
執行測試
↓
讀取錯誤
↓
再次修改
↓
完成驗證

如果每一步都需要人工批准，Agentic Coding 的自主工作能力就會大幅降低。

Read-only、Workspace-write、Danger-full-access 怎麼分？

可以用非常簡單的方式理解這三個層級。

Read-only：只能看

sandbox_mode = "read-only"

適合：

• 程式碼分析
• 專案研究
• 問問題
• Code Review

Codex 可以查看內容，但不能正常修改工作區檔案。OpenAI 也把 Read-only 定位為適合安全瀏覽專案的模式。

Workspace-write：工作區內可以改

sandbox_mode = "workspace-write"

適合：

• AI Coding
• Debug
• Refactoring
• 自動測試
• Agentic Coding

工作區內一般檔案可以被修改，因此也應該把刪除檔案視為可能發生的變更。

Danger-full-access：移除本機 Sandbox 限制

sandbox_mode = "danger-full-access"

這種模式會移除本機 Sandbox 限制，因此應該只在你明確知道為什麼需要如此廣泛權限時使用。OpenAI 官方同樣將這個模式標示為需要謹慎使用。

簡單記：

Read-only
只能看

↓

Workspace-write
工作區內可以改

↓

Danger-full-access
移除本機 Sandbox 限制

如果我希望「可以修改，但刪除一定要問」呢？

這可能是許多開發者真正想要的模式：

Codex 可以自由修改程式碼，但是刪除檔案前一定要讓我確認。

這時需要注意：

approval_policy = "on-request"
sandbox_mode = "workspace-write"

本身不能直接視為「刪除確認開關」。

因為 on-request 的主要用途仍然是管理 Sandbox 邊界的核准，而不是針對每一種檔案操作逐項詢問。

OpenAI 目前也提供 Rules、granular approval policy 等更細部的控制機制，可以針對特定命令或核准類別做進一步限制；這類設定比單純擴大或縮小 Sandbox 更適合需要精細治理的情境。

Git 為什麼變得更重要？

當開始大量使用 Agentic Coding，我認為 Git 的角色會比以前更加重要。

以前 Git 主要用於：

版本控制
+
團隊協作
+
程式碼追蹤

現在還多了一項重要用途：

成為 AI Agent 修改程式碼後的復原機制。

假設在讓 Codex 開始進行大型 Refactoring 之前，先建立一個乾淨的 Commit：

git status
git add .
git commit -m "Before Codex refactoring"

接著再讓 Codex 工作。

完成後可以先查看：

git status

再利用：

git diff

確認：

• 哪些程式被修改
• 哪些檔案被新增
• 哪些檔案被刪除

如果 Agent 判斷錯誤，也比較容易回復到之前的狀態。

此外，Codex 預設 workspace-write 還會把 .git 等特定路徑保持唯讀，提供額外的保護層。

Agentic Coding 時，我會怎麼搭配？

如果是一般本機開發，我會優先採用：

approval_policy = "on-request"
sandbox_mode = "workspace-write"

讓 Codex 有足夠的權限完成：

讀取
↓
修改
↓
測試
↓
修正
↓
再次驗證

同時搭配三個習慣：

第一，重要修改前先 Commit。

讓自己隨時有一個可復原的版本。

第二，Agent 完成後檢查 git diff。

不要因為 AI 說「完成了」就直接接受所有修改。

第三，不必要的目錄不要加入 writable roots。

OpenAI 提供 writable_roots 的目的，就是讓使用者只增加真正需要 Codex 修改的其他路徑，而不是直接取消整個 Sandbox。

一分鐘快速記住

如果只想記住這篇文章最重要的幾件事，可以記這四句：

Read-only：只能看，不能正常修改。

Workspace-write：工作區內可以新增、修改，也可能刪除一般可寫入檔案。

On-request：不是每次刪檔都詢問，而是在需要跨越 Sandbox 邊界時進入核准流程。

Git：是使用 Agentic Coding 時非常重要的復原安全網。

結語：AI Coding 開始進入「權限管理」時代

當 AI 只是聊天機器人時，我們比較在意的是：

Prompt 寫得好不好？

但當 Codex 這類 Coding Agent 可以：

讀取檔案
修改程式
執行命令
跑測試
重構專案
處理檔案

問題就開始改變。

我們除了需要學習 Prompt，也必須開始理解：

這個 AI Agent 到底被授予了哪些權限？

workspace-write 很適合實際開發，因為它讓 Codex 真正有能力完成多步驟任務；但同時也意味著，工作區內的一般檔案並不是完全不會被改動或刪除。OpenAI 將 Sandbox 與 Approval Policy 分開設計，也正是要讓使用者能同時控制「Agent 能做到哪裡」以及「何時需要停下來要求額外授權」。

對 Agentic Coding 而言，我認為更合理的做法不是讓 AI 完全不能動，而是建立：

Sandbox 權限邊界 ＋ Approval Policy ＋ Git 版本控制 ＋ 人工審查

讓 AI 有能力工作，同時保留可以檢查、追蹤與復原的安全機制。

這才會是從「會用 AI 寫程式」，逐步走向「能安全管理 AI Agent」的重要一步。