Codex 操作正式伺服器前：sandbox、approval 與 SSH 權限檢查
請 Codex 重啟服務，真正要授權的是哪個主機、哪個服務，以及哪一條命令。只在提示裡寫「只做我要求的事」，仍缺少可執行範圍的限制。
正式機操作先從唯讀診斷開始，再由人核對具體變更；執行端使用受限帳號，Codex 的 sandbox 與 approval policy 則分別限制技術邊界和核准流程。 SSH、MCP 或雲端 API 的目標端權限也要一起檢查。
2026-11-03 的 Codex issue #59060有使用者回報重開機任務引發額外系統變更。公開回報不足以重建完整執行環境與權限設定，本文據此提出操作前檢查問題；權限行為以 OpenAI 文件與本機 CLI help 為依據。
sandbox 管能做什麼，approval 管何時詢問
OpenAI 的權限文件區分兩層設定：sandbox 限制命令的檔案與網路存取，approval policy 決定何時提出核准。never 表示不跳核准提示；實際可執行範圍仍取決於 sandbox。
| 組合 | 適合先檢查的用途 |
|---|---|
read-only + on-request | 讀取允許存取的資訊，產生操作計畫；遇到超出邊界的動作可提出核准 |
workspace-write + on-request | 在限定工作區準備修補與測試，越界操作另行審核 |
danger-full-access + never | 移除 sandbox 限制並略過核准提示，需由外部隔離承擔邊界 |
可先在放有脫敏紀錄的本機工作目錄啟動以下互動式 CLI。這是供讀者執行的啟動示例，本文只核對旗標，沒有建立新的模型工作階段：
codex --sandbox read-only --ask-for-approval on-request進入後以 /permissions 查看權限選擇，以 /status 核對目前模式與可寫路徑；若環境受管理政策約束，再用 /debug-config 檢查設定層。read-only 允許的讀取仍可能包含敏感資料，收集診斷時應只帶入必要且已遮罩的內容。
Sandbox 文件與本機 0.166.0-alpha.5.1 的 help 都列出上述 sandbox 模式及 on-request／never。舊設定若仍用 approval_policy = "untrusted"，要依官方遷移文件處理；它已不再是可選的 approval policy。--approve-for-me 則會將核准交給自動審查，正式機逐項人工審核可明確保留 approvals_reviewer = "user"。
SSH 的遠端操作要由遠端帳號限制
本機 sandbox 約束本機啟動的命令。若允許 SSH 連線，遠端程序會以遠端帳號的權限執行；本機工作區的路徑邊界無法直接替遠端檔案系統設定寫入範圍。這是依程序與權限位置做出的操作判斷。
因此先回答三個問題：
- 連的是測試機還是正式機？以連線設定和主機資訊比對，避免只信聊天中的主機名稱。
- 該帳號能否修改系統檔、使用 sudo、控制 Docker 或調用雲端管理 API？把可用憑證和現有授權列入檢查。
- 若任務只需要一個服務動作，能否由維運端提供只允許該動作的入口，或由人執行已核對的命令？
使用正式機管理帳號時，將命令包成腳本仍須檢閱腳本內容、參數及所呼叫的其他程式。命令名稱看起來簡單，不能代表作用範圍已縮小。MCP 與 Apps 也有各自的權限與核准路徑；可先做 MCP 能力盤點，只連接本次需要的工具。
把核准寫成可以比對的操作單
先讓 Agent 只產生計畫，列出目標主機、操作對象、預計命令、會寫入的路徑、預期中斷，以及失敗時的復原方式。例如「只重新啟動指定服務；若發現磁碟掛載問題，回報資訊並停止」，能讓額外修復成為新的決策點。
人工審核時比對命令與計畫，尤其查看 shell 串接、重新導向、下載後執行、sudo 和容器控制。核准畫面提供單次與較長範圍時，選符合這次動作的範圍。需要修改 /etc/fstab 等開機相關設定時，另開變更步驟，先由管理者確認備份、主控台存取與復原路徑。
完成後以獨立終端機或監控確認服務狀態，再比對本次允許變更的設定與稽核紀錄；有 Git 的工作區可用 diff 與 staged 狀態分流。若結果超出操作單，先保留證據與現況，再決定復原。
2026-11-04 維護流程在 macOS 執行 codex --version、codex --help，只確認本機版本與旗標。本文沒有連線正式機、修改權限、測試 sandbox 阻擋或執行重啟；上面的流程仍需在自己的受控環境驗收。
參考資料：