grok-plugin-codex — 在 Codex 裏使用 Grok

一眼看懂

角色獨立開發者 — Codex plugin 打包、MCP tool surface、Grok CLI 編排、隱私邊界、背景任務、測試

問題

Grok 可以提供另一個工程視角，但手動切換工具會讓 scope、session history 與審查責任變得難控。這個項目的目標，是讓 Codex 能請 Grok 協助，同時仍由 Codex 掌握文件、測試、git 與最終判斷。

解法

我把 Grok CLI 包成 Codex 裡的 MCP 工具，加入能力檢查、受控 run / review / rescue 包裝、session 列表與匯出、背景任務 status / result / cancel，以及針對隱藏 context 與 private runtime paths 的明確保護。

成果

公開 Codex plugin · 0.2 typed MCP contract 與 explicit workspace roots · Codex 內的 Grok review 與 rescue · 受控第二 agent 工作流

我的工作

Codex plugin 暴露 Grok MCP 工具：check、models、run、continue、rescue、review、adversarial review、sessions、export、status、result、cancel
受控 review 與 rescue helper，讓 Grok 可以作為第二雙眼睛，但不成為改動 owner
Background Grok job 管理，包含 status / result / cancel，讓長時間 review 可先檢查再採信
0.2 typed MCP contract 將 session 列表與匯出保留為明確 evidence surfaces，同時仍刻意不聲稱已有 Codex-to-Grok transfer 路徑
0.2 release 變更：breaking typed MCP contract、explicit workspace roots、restart-safe background workers、atomic job lifecycle、經 fd3 的 private prompt staging，以及更嚴的 path、symlink、env、session、cancel 邊界

技術證據

TypeScript 編寫的 bundled stdio MCP server，打包為 Codex plugin，包含 plugin manifest、skill、MCP config、privacy policy、terms 與 security policy
Grok CLI 發現、版本檢查、可選 model probing、foreground JSON run、streaming background run、job ledger，以及保守的 result completion 判定
按設計收窄隱私邊界：prompt 不接收 Codex hidden context、tool output、secrets 或 Grok auth token；private runtime path 請求默認拒絕，除非明確允許
驗證腳本覆蓋 build、typecheck、unit tests、MCP smoke checks、documentation drift checks，以及可選的 authenticated live Grok smoke

為什麼做它

實際用途是可控協作。Codex 可能已經深入一個 repo，需要另一個模型幫忙 review diff、診斷失敗或挑戰假設。這個 plugin 給 Grok 一個清楚任務包，但 scope、驗證與是否交付仍由 Codex 負責。

對非技術讀者來說，重點不是又多了一個模型能說話，而是一個更安全的工作流：可以請第二方給意見，但主要 assistant 仍掌握控制權，所有結論都要驗證後才改代碼。

受控的 Grok 協作

流程先用 grok_check 確認本機 Grok CLI。grok_run 處理受控任務；grok_review、grok_rescue 與 grok_adversarial_review 則把第二 agent 的工作限制在 finding 或 diagnosis，而不是失控接管。

背景任務採取保守判定：partial logs 只算過程證據；只有在 plugin 看到成功結束與最終文本後，才把結果當作可用結論。