将 GitHub 接入 Codex

在 Codex 中查看 GitHub 待合并 PR。连接账号、选择仓库,即可通过 OOMOL MCP 读取最多 5 个开放 PR。

开始使用 GitHub

开始使用 GitHub

通过 OAuth 授权连接 GitHub 账号。

先确认资源访问权限

一个有权访问目标仓库的 GitHub 账号。

连接 GitHub

登录 OOMOL,选择团队,在 GitHub 连接页使用支持的授权方式创建连接。确认连接处于活跃状态,然后在 MCP 配置或 oo CLI 登录中使用同一个团队。

连接 GitHub
  • 一个有权访问目标仓库的 GitHub 账号。
  • 仓库授权使用 repo scope,包含读取和写入权限。具体操作还受账号在仓库中的权限限制。
选择接入方式

适合支持远程 HTTP MCP 和自定义认证请求头的客户端。

  1. 打开 MCP 配置页,登录并选择应用连接所在的团队。点击“复制 MCP 配置”获取密钥和请求头。
  2. 按下方 MCP 客户端说明添加配置,再重新连接客户端。
  3. 将只读验证任务复制到 AI 对话中执行。
配置 MCP MCP 客户端配置 →

适合能运行终端命令并使用 oo Skill 的 Agent。

  1. 按照 Agent 安装页的说明,安装 oo CLI 和 oo Skill。
  2. 登录应用连接所在的 OOMOL 团队。使用 oo login --team <team-name>,将占位符替换为团队名称。
  3. 将只读验证任务复制到 Agent 对话中执行。
安装 oo CLI + Skill CLI 安装指南 →

MCP 客户端配置

获取 MCP 配置

用 OOMOL 配置页中的密钥和团队名称替换占位符。请妥善保管凭证,并保留已有的其他服务配置。

Codex

打开 ~/.codex/config.toml,添加或更新唯一的 oomol 配置,将 <team-name> 替换为复制配置中的团队名称。在启动 Codex 的进程环境中设置 OOMOL_MCP_API_KEY,值为 Authorization 中的密钥本身,不包含 Bearer 前缀。删除 oomol.http_headers 中旧的 Authorization 项,不要把密钥写入 config.toml。使用该环境重新启动 Codex。

[mcp_servers.oomol]
url = "https://connector.oomol.com/v1/mcp"
bearer_token_env_var = "OOMOL_MCP_API_KEY"

[mcp_servers.oomol.http_headers]
"x-oo-team-name" = "<team-name>"

在 macOS 或 Linux 上使用 Codex CLI 和 Bash 时,运行以下命令,在不回显的提示处粘贴密钥。密钥只传给本次 Codex 进程,不会写入文件或命令历史。桌面端或 IDE 客户端需要在各自的启动环境中获得同名变量;另一个终端中设置的变量不一定可用。

bash -c '
read -r -s -p "OOMOL MCP API key: " OOMOL_MCP_API_KEY || exit 1
export OOMOL_MCP_API_KEY
exec codex
'
验证连接
  1. 在 Codex CLI 中使用 /mcp 检查 oomol;桌面端或 IDE 客户端则查看其 MCP 状态。确认启动进程能读取 OOMOL_MCP_API_KEY,再新建对话。
  2. 在新的 AI 对话中执行只读验证任务,确认能读取目标资源及其数据。

检查是否出现 connector_list_apps、connector_search_actions 等 OOMOL 工具。它们用于发现和执行 GitHub 操作,各操作不一定单独出现在 MCP 工具列表中。 常见问题 →

验证第一次 GitHub 查询

将此只读任务复制到新的 AI 对话中执行。查询失败时,请查看常见问题。

选择接入方式

验证第一次 GitHub 查询

核对返回的资源标识是否与你的目标一致,并查看查询结果。

仅使用 OOMOL MCP。 检查当前配置的 OOMOL 团队中是否有活跃的 GitHub 连接。读取已连接 GitHub 用户,列出可访问仓库并让我选择一个。读取最多 5 个开放的拉取请求,返回仓库、PR 编号、标题、链接及实际可见的草稿标记。不要推断审查是否通过或检查是否成功。目标不明确时请让我选择。只报告实际结果,注明选定资源,并区分空结果与访问错误。不要创建、修改、删除或发送任何内容。

常见问题

为什么连接成功却读不到资源?
使用包含活跃应用连接的 OOMOL 团队。应用授权、MCP 密钥和资源访问权限需要分别检查。根据工具实际错误核对资源标识和查询范围,分别报告空结果与访问错误,并妥善保管密钥。 GitHub 需要核对已连接用户及仓库访问权限。repo 授权范围包含写入权限,本次首次任务仅执行读取。PR 列表不能证明审查、CI 检查或合并权限已通过。
AI 可以在整理 Issue 时帮我找出什么?
可以归纳相关报告、总结评论,并找出缺少的复现步骤。请指定仓库和筛选条件;如需判断优先级,也请提供影响程度和紧急程度的依据。
AI 可以访问私有仓库吗?
取决于已授予的 repo scope 和当前账号的访问权限。连接不会绕过仓库权限。
让 AI 分析 Pull Request,需要提供什么?
提供 Pull Request 链接和你关注的审查方向。助手可以总结变更文件,并根据返回的 diff 分析潜在风险;缺少上下文时应明确指出,分析结果仍需审阅。
分析 Pull Request 会提交审查或自动合并吗?
读取 Pull Request 和变更文件不会提交审查或合并。它们是单独的操作,需要明确要求执行。