Advanced: Use Codex with GitHub MCP for a Read-Only Pull Request Review

This is an advanced builder lesson. It uses Codex MCP support and GitHub’s official MCP Server documentation to inspect one pull request. The output is a review note, not an approval and not a code change.

The example is documentation-based and illustrative. It does not claim that this connection was run by Cihan, that a pull request was returned, or that a review finding was correct.

What you need

Codex CLI or the Codex IDE extension with MCP support
a GitHub account with access to a test repository
permission to configure an MCP server and a least-privilege token or approved authentication method
one pull request that is safe to inspect

GitHub documents a hosted remote MCP server at https://api.githubcopilot.com/mcp/ and a Codex setup path. Read the current provider documentation before configuring access. Do not put a token in a prompt, commit it, or grant write scopes for this exercise.

No-code alternative

Open the pull request in GitHub, read the changed-files tab, and record the same review fields in a short note. This is the better choice if you only need one review or cannot verify the Codex and MCP permissions.

Safe sample task

Use a test repository named example-org/example-repo and pull request number 27. Ask for changed-file names, the pull request title, author, base branch, head branch, and review questions. Do not ask the connection to approve, merge, edit, comment, assign, close, or reopen anything.

Steps

Read the current Codex MCP documentation and GitHub’s Codex installation guide in the Sources section.
In Codex, configure GitHub using the documented remote server and your approved authentication method. Keep the credential in the environment or credential store recommended by the provider.
Inspect the configured account and scopes before accepting access. Stop if the connection exposes more access than the review requires.
Confirm that the GitHub server appears in Codex’s MCP list. If it does not, fix the configuration rather than widening permissions.
Run the bounded read-only request below for pull request 27.
Open the pull request in GitHub and compare the returned metadata and changed-file list. Treat any suggested concern as a question for the code owner, not as proof of a defect.
Save the review note and disconnect the server when the inspection is complete if you do not need the connection again.

Copyable read-only instruction

Use the connected GitHub MCP server for one read-only pull request inspection.

Repository: example-org/example-repo
Pull request: 27

Return a review note with:
- pull request title, author, base branch, and head branch
- changed file paths
- up to five questions about missing tests, unclear scope, or risky behavior
- the exact file path or diff context for each question

Do not create, edit, comment on, approve, assign, close, reopen, merge, or delete anything.
Do not claim that a question is a defect.
If the repository or pull request cannot be read, report the exact limitation and stop.
Do not infer missing fields.

Illustrative output

A useful review note might look like this:

Repository: example-org/example-repo
Pull request: 27
Changed files: src/export.ts, tests/export.test.ts
Question: The new CSV branch has no visible test for an empty input. Check whether that case is covered elsewhere.
Context: src/export.ts, CSV branch near the new parser call.

Status: questions for human review. No approval or merge action taken.

This is an illustrative artifact, not a returned Codex result. Replace every line with values you verify in GitHub.

Acceptance checks

The review passes when:

the repository and pull request number match the request
title, author, base branch, head branch, and changed files match GitHub
every question points to a real file or diff context
the note separates questions from confirmed defects
the activity log shows read operations only
no write tool was used and no approval or merge was implied

Troubleshooting

The GitHub server is not listed. Check the Codex MCP configuration syntax and authentication for the same client. Do not add broader scopes as a first response.

The pull request is unavailable. Confirm the repository spelling, pull request number, and account access. If it is private, check that the approved account is the one connected.

The server exposes write tools. Stop the exercise. Review the provider scopes and client permissions, then use the no-code alternative until the access boundary is clear.

The review says a change is definitely broken. Rewrite it as a question and verify the file and diff context yourself. A read-only model response is not a test result.

Limits and privacy

MCP connects a model to external tools. A read-only prompt does not replace account scopes or client approvals. Use test repositories first, keep secrets out of prompts, and never treat a review note as permission to merge or deploy.

TRY one pull request in a test repository with an owner who can check the note.

SKIP unattended code changes or broad repository access.

USE the review note as a preparation artifact before a human code review.

For one practical AI-for-work workflow each week, join The Weekly Verdict.