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.3.0，在 typed MCP 界面上报告 contract version 3，并带 explicit workspace roots · Codex 内的 Grok review 与 rescue · 受控第二 agent 工作流

我的工作

Codex plugin 暴露十三个 Grok MCP 工具：check、models、run、continue、finalize、rescue、review、adversarial review、sessions、export、status、result、cancel
受控 review 与 rescue helper，让 Grok 可以作为第二双眼睛，但不成为改动 owner
后台 Grok job 管理，包含 status / result / cancel，让长时间 review 可先检查再采信
typed MCP contract 让 session 列表与导出可供检查；目前的协作路径以这些明确 evidence surfaces 为终点
0.3.0 在该基线上继续：background dispatch 成为默认，grok_finalize 加入工具面，每个未完成结果都带机器可读的 recovery handle；prompt staging 也离开了 /dev/fd/3 — Linux 会经 /proc/self/fd 解析它，可能交给 Grok 一个已被消费的空流，因此 prompt 现在走一个私有目录里的 0600 FIFO，并在 Grok 读取前就 unlink

技术证据

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 判定
按设计收窄隐私边界：Grok 接收任务 prompt 与已批准文件；Codex hidden context、tool output、secrets 与 auth tokens 留在各自来源中，private runtime paths 则需要明确许可
验证脚本覆盖 build、typecheck、unit tests、MCP smoke checks、documentation drift checks，以及可选的 authenticated live Grok smoke

为什么做它

实际用途是可控协作。Codex 可能已经深入一个 repo，需要另一个模型帮忙 review diff、诊断失败或挑战假设。这个 plugin 给 Grok 一个清楚任务包，但 scope、验证与是否交付仍由 Codex 负责。

对非技术读者来说，它提供的是一套更安全的第二意见流程：Grok 补充另一个工程视角，Codex 继续主导，每项发现都经检查后才进入代码改动。

受控的 Grok 协作

流程先用 grok_check 确认本机 Grok CLI。grok_run 处理受控任务；grok_review、grok_rescue 与 grok_adversarial_review 返回聚焦的 findings 或 diagnosis，再由 Codex 验证。

后台任务成功结束并返回最终文本后，结果才进入可用状态；partial logs 则保留为可见的进度证据。