Codex App: make Pull Requests navigation provider-agnostic and configurable

Open 💬 2 comments Opened Jul 14, 2026 by jiangyuan

What variant of Codex are you using?

Codex App 26.707.72221 on macOS.

What feature would you like to see?

The top-level Pull Requests navigation in Codex App should be provider-agnostic and configurable instead of being hard-wired to GitHub and the gh CLI.

Many enterprise users work in local Git repositories backed by an internal or self-hosted SCM. For those users, a permanent Pull Requests item whose implementation assumes GitHub is not useful. It also makes a generic Git workflow appear dependent on one hosting vendor, even when the actual merge-request workflow is handled through another CLI, MCP server, or plugin.

Please support:

A configurable SCM provider interface for pull/merge request context:

detect providers from Git remote URLs;
allow built-in and custom providers;
allow a CLI, MCP server, or plugin adapter to resolve the current branch to its pull/merge request;
let providers define terminology such as "Pull Request" or "Merge Request".

An option to hide or disable the Pull Requests navigation when no supported provider is configured.
Scope gh discovery and authentication to the GitHub provider instead of treating it as a general prerequisite for this navigation.

Expected behavior

Local Git, diff, branch review, and uncommitted-change review remain provider-agnostic.
Selecting the Pull Requests navigation delegates to the configured provider.
Non-GitHub repositories do not show GitHub-specific authentication or availability states.
Users who do not use any hosted review workflow can remove the unused navigation item.

Why this matters

Codex already supports extensibility through CLIs, MCP servers, plugins, and skills. The pull/merge request surface should use the same model instead of coupling the product navigation to a single SCM vendor.

Related issues:

openai/codex#30038 covers configurable Git providers and credentials.
openai/codex#26963 covers GitLab merge-request links.
openai/codex#29849 covers hiding GitHub PR status in non-GitHub workspaces.

This request focuses specifically on making the top-level Pull Requests navigation and its provider contract configurable, so enterprise and self-hosted SCM integrations can participate without requiring GitHub or gh.

View original on GitHub ↗

2 Comments

alario-tang · 1 month ago

补充一个来自 CNB（cnb.cool）仓库的实际使用场景。

目前本地 Git 工作流本身完全正常，CNB CLI 也能够查询、查看、评论、评审和合并 PR；当前分支在 CNB 上已经存在 PR。但 Codex App 顶层“Pull Requests”页面仍然为空，因为这块界面只理解 GitHub/gh，并不会根据 Git remote 选择其他实现。即使额外配置 git pr alias 也没有作用，因为 App 没有把 PR 操作委托给可配置命令。

对我们而言，一个有用的 MVP 不一定需要立即为每个代码托管平台内置完整集成。可以先定义一个最小 Provider contract：

根据 remote URL 选择 Provider；
支持 list、view、diff 和 open-in-browser；
允许由 CLI、MCP 或插件实现 Adapter，并复用 Adapter 自己的登录态；
Provider 声明自身支持的可选能力，例如 comment、review、checks、merge；
未配置 Provider 时隐藏 PR 导航，而不是显示 GitHub CLI 不可用。

接口层最好区分三类能力：本地 Git 数据、托管平台的 PR 元数据，以及评论/评审/合并等写操作。这样 CNB、GitLab 和其他自托管平台可以先接入只读能力，再逐步补充写操作，而不需要一次实现 GitHub GraphQL 的全部等价功能。

abcdlsj · 21 days ago

I prepared a small provider-aware implementation for the CLI/TUI status-line surface:

GitHub uses the provider terminology PR #123.
GitLab uses MR !123.
GitLab.com and self-hosted GitLab are supported through glab and the current repository remote/auth configuration.
Provider-specific review-request URLs remain clickable.
Provider lookup failures stay silent and optional.

Branch: https://github.com/abcdlsj/codex/tree/release/codex/hosted-review-statusline
Compare: https://github.com/openai/codex/compare/main...abcdlsj:release/codex/hosted-review-statusline?expand=1

This is deliberately narrower than the top-level Pull Requests provider contract proposed here: it covers status-line detection/display, not listing, comments, reviews, or merge operations. The upstream PR is blocked by the contributing account having READ-only permission on openai/codex, but the implementation branch is available for review.