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
后台 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 看到成功结束与最终文本后，才把结果当作可用结论。