Should API allow reviewing merged PRs? Web UI prevents, but API allows

[davidxia]

Select Topic Area

Question

Body

The API allowing reviewing merged PRs right now causes inconsistency and confusion between web UI (prevents this behavior) and other API clients like the gh CLI.

See cli/cli#5038

I am loath to say this but I think we need to close this as won't fix. I don't like that you can review merged PRs; it's a spam vector that we, like any other big open source project on GH, suffer from. That said: it's explicitly allowed by the API, and if I think enough I can concoct some kind of contrived bureaucratic scenario where someone might want this feature?

Either way, I don't think the CLI is the right place to tackle this.

I recommend talking about this here: https://github.com/github/feedback/discussions/categories/pull-requests-feedback , which covers the pull requests feature itself at the platform level.

I personally like being able to review merged PRs. I think maintainers should rely on locking an issue or PR to prevent spam since people can still spam by commenting on merged PRs.

[KaweMaximo]

Thanks for raising this — the inconsistency between the Web UI and API behavior here is a real pain point, especially for teams building tooling on top of the API that expect parity with what the UI enforces.

A few thoughts:

The current state creates real problems:

• Automation and bots can submit reviews on merged PRs via the API, which clutters notification feeds and can confuse contributors
• CI/CD pipelines and GitHub Apps that mirror UI behavior have to implement their own guards against this
• It erodes trust in the API as a reliable contract when behavior diverges from the UI

Suggested resolution:
The API should return a 422 Unprocessable Entity (or similar) when a review is submitted against a merged or closed PR — matching the existing Web UI constraint. A clear error message like "Reviews cannot be submitted on merged pull requests" would make the intent explicit.

For any consumers relying on the current behavior, a deprecation notice + grace period would be the right path.

Re: the spam concern in cli#5038 — agreed that locking is the right mitigation for maintainers, but that doesn't preclude also closing this API inconsistency. Both can be true.

Happy to help test or provide reproduction steps if that's useful.

[ash-iiiiish]

Regarding the API behavior that allows reviewing merged pull requests, causing inconsistency between the web UI (which prevents this) and API clients like the gh CLI.

Summary of the situation:

The GitHub API currently permits reviews on merged pull requests

The web UI blocks this behavior, creating inconsistency across clients

This has been flagged as a spam vector affecting large open-source projects

The issue was raised in the CLI repository (cli/cli#5038)

Community consensus points:

The inconsistency between web UI and API behavior creates confusion

Allowing reviews on merged PRs can be exploited for spam, similar to comments

Some maintainers argue that locking PRs is the proper defense against spam, not API restrictions

Others believe the API should mirror web UI behavior for consistency

Recommended path forward:

This is a platform-level API behavior issue, not a CLI-specific problem. The appropriate venue for discussing this is the official GitHub feedback forum for Pull Requests:

https://github.com/github/feedback/discussions/categories/pull-requests-feedback

[shivrajcodez]

Thanks for raising this — the inconsistency between the web UI and the API behavior is definitely understandable from a maintainer perspective.

Right now the behavior seems to come from a design difference between the GitHub Web Interface and the GitHub API. The web UI intentionally prevents submitting reviews on already merged pull requests, while the API still allows it. Because the GitHub CLI relies on the API, it ends up inheriting that behavior.

From a tooling perspective, it makes sense that the CLI wouldn’t enforce stricter rules than the API itself, since that could create unexpected behavior for users who depend on the API’s current capabilities.

Also worth noting: even if reviews were blocked on merged PRs, maintainers would still need moderation tools because spam can still occur through comments. In practice, the most reliable mitigation is usually repository-level controls such as:

• locking the pull request once it’s resolved
• enabling moderation or interaction limits
• using automation to detect spam patterns

Given that this behavior originates at the platform level, discussing it in the GitHub Pull Requests feedback category is probably the right route so the GitHub platform team can evaluate whether the API and UI should behave consistently.

Personally, I can also see legitimate use cases for post-merge reviews (for example retroactive code review, audit notes, or training feedback), so any change would likely need to be considered carefully to avoid breaking workflows that depend on the current API behavior.

Appreciate the thoughtful discussion around this.