Describe the feature or problem you'd like to solve
When using add_comment_to_pending_review to leave a code review, the comment is silently dropped at submit time if the targeted line is outside the PR's diff hunks (e.g., unchanged context further up the file). The tool returns success on add_comment_to_pending_review, but pull_request_review_write { method: "submit_pending" } accepts the review without that comment ever appearing on the PR.
This means agents reviewing PRs cannot leave inline comments on file context that is relevant to a change but happens to sit outside the modified lines — for example, stale JSDoc on an exported interface that should be updated to reflect a new feature added several lines below.
In the GitHub web UI, a human reviewer can expand context and click any line in any file to add a comment. Agents using this MCP server cannot match that capability.
Proposed solution
Two parts:
-
Surface the failure. When a comment is dropped because the targeted line is outside the diff, return an error from add_comment_to_pending_review (or surface it on submit) so the agent can fall back to subjectType: "FILE" or a top-level comment. Today the tool reports success and the rejection happens silently inside GitHub's submit step.
-
Support arbitrary file lines. Use the GraphQL addPullRequestReviewThread mutation (which accepts path + line without requiring a diff position) when the requested line is outside the unified diff. This would give agent reviewers the same expressive power as human reviewers in the UI.
Example prompts or workflows (for tools/toolsets only)
- "Review this PR — flag any stale JSDoc/comments on exported APIs whose contract changed." Today the agent can correctly identify stale documentation but cannot leave the inline comment if the JSDoc itself isn't in the diff.
- "Suggest renames for the helper functions used by the new code." If the helpers themselves are unchanged, the agent can't comment on them inline.
- "Note any security-relevant invariants the changes rely on." Often these are documented elsewhere in the file, outside the diff.
Additional context
Repro:
- Open any PR with a small, localized diff.
- Use
pull_request_review_write { method: "create" } to start a pending review.
- Use
add_comment_to_pending_review targeting an unchanged line ≥30 lines from the diff. Tool returns success.
- Use
pull_request_review_write { method: "submit_pending" }. Review submits without the comment.
- Verify on the PR — the comment is missing.
Workaround today: use subjectType: "FILE" for file-level comments, or post a top-level issue comment with a permalink. Both lose the inline-thread experience.
Related but distinct: #1748 (fork-PR auth scope) — same symptom (comment doesn't post) but a different root cause.
Describe the feature or problem you'd like to solve
When using
add_comment_to_pending_reviewto leave a code review, the comment is silently dropped at submit time if the targeted line is outside the PR's diff hunks (e.g., unchanged context further up the file). The tool returns success onadd_comment_to_pending_review, butpull_request_review_write { method: "submit_pending" }accepts the review without that comment ever appearing on the PR.This means agents reviewing PRs cannot leave inline comments on file context that is relevant to a change but happens to sit outside the modified lines — for example, stale JSDoc on an exported interface that should be updated to reflect a new feature added several lines below.
In the GitHub web UI, a human reviewer can expand context and click any line in any file to add a comment. Agents using this MCP server cannot match that capability.
Proposed solution
Two parts:
Surface the failure. When a comment is dropped because the targeted line is outside the diff, return an error from
add_comment_to_pending_review(or surface it on submit) so the agent can fall back tosubjectType: "FILE"or a top-level comment. Today the tool reports success and the rejection happens silently inside GitHub's submit step.Support arbitrary file lines. Use the GraphQL
addPullRequestReviewThreadmutation (which acceptspath+linewithout requiring a diff position) when the requested line is outside the unified diff. This would give agent reviewers the same expressive power as human reviewers in the UI.Example prompts or workflows (for tools/toolsets only)
Additional context
Repro:
pull_request_review_write { method: "create" }to start a pending review.add_comment_to_pending_reviewtargeting an unchanged line ≥30 lines from the diff. Tool returns success.pull_request_review_write { method: "submit_pending" }. Review submits without the comment.Workaround today: use
subjectType: "FILE"for file-level comments, or post a top-level issue comment with a permalink. Both lose the inline-thread experience.Related but distinct: #1748 (fork-PR auth scope) — same symptom (comment doesn't post) but a different root cause.