Codex Cloud 支援 GitLab Beta：Issue 與 Merge Request 要先檢查什麼？

這次 Beta 實際涵蓋哪些 GitLab 流程#

目前可以把 GitLab 內容接到三種工作入口：

一個實用的分界是：先把 Issue 當成任務入口，把 Merge Request 當成變更與審查入口。不要因為可以從 MR 啟動工作，就把「完成 review」理解成「已經替團隊決定可以合併」；實際的 branch policy、測試與人工審查仍要留在 GitLab 流程內。

如果你也在管理 Codex 的 plugins、connector 或其他可執行能力，可以先看 Codex Plugin Directory 的權限檢查，把「能連到哪裡」與「連上後能做什麼」分開盤點。

Self-Managed GitLab 的門檻不只是一個 URL#

OpenAI 官方更新對 Self-Managed 與 Dedicated GitLab 列出兩個額外條件：workspace 管理員必須完成連線設定，而且 GitLab 版本需要是 19.0 或更新版本。GitLab-triggered activity 還需要能設定適用 webhook 的權限；如果只把 project URL 貼進設定頁，並不代表 Issue 或 MR 事件已經能觸發 Codex。

建議先用下面的清單和管理員確認：

1. 目前使用的是 GitLab.com、Self-Managed，還是 Dedicated。
2. Self-Managed／Dedicated 的 GitLab 版本是否至少為 19.0。
3. workspace 是否允許 GitLab connector，管理員是否已完成必要設定。
4. 觸發活動的帳號是否能設定該 project 或 instance 的 webhook。
5. Codex Cloud 建立的 environment 是否能取得測試所需的依賴與執行指令。

這些條件分屬 workspace、GitLab 管理與 project 權限。當任務沒有啟動時，先分層檢查，比反覆修改 Issue 文字更容易找出卡點。

自動 Merge Request review 先從小範圍開始#

第一次測試建議選一個不含 production secrets 的 repository，並依序驗證：

1. 連接 project，建立 Codex environment，確認環境可以完成一個只讀任務。
2. 在測試 Issue 使用 @codex，保留觸發時間、任務輸出與實際變更範圍。
3. 對一個小型 MR 先做一次性 review，確認 review 看到的 diff、測試指令和 repository 權限都符合預期。
4. 只有在人工 review 結果可重現後，才評估自動 review；同時設定失敗通知與人工接手路徑。

OpenAI 也特別說明，當 GitLab 沒有提供完整 diff，例如 diff 被折疊或規模過大時，Codex 無法完成 review。這類失敗不一定是模型或 webhook 故障，應先回到 MR 的 diff 是否可完整提供，以及變更是否能拆成較小的可審查單位。

結論：把 GitLab connector 當成新的雲端執行邊界#

Codex Cloud 的 GitLab Beta 適合先從明確的 Issue 任務和小型 Merge Request 開始。連接完成只代表 project 可以被 Codex Cloud 看見；workspace policy、webhook 權限、environment、diff 完整性和最後的人工審查，仍然是五個不同的驗證點。

常見問題#