How to connect a GitHub MCP with Codex (4 steps)

When you assign Codex a task to fix a bug or implement a feature, you usually paraphrase the GitHub issue into the prompt.

That paraphrase drops the reproduction steps buried in the thread, the constraint a maintainer added in a comment, and the linked PR that already tried one approach.

The full context lives in GitHub, not in your one-line summary. So Codex writes a fix that ignores the edge case someone already flagged, reimplements an approach that was rejected, or breaks a convention the codebase follows everywhere else.

To give Codex direct access to GitHub as it works through your coding tasks, we'll show you how to connect GitHub with Merge Agent Handler's GitHub MCP server.

How it works

Merge Agent Handler connects Codex to the GitHub API through the Merge CLI. You install the CLI, authenticate once, and run a single setup command from your project root.

That command writes a Merge CLI section to your project's AGENTS.md file, which tells Codex when to call merge search-tools and merge execute-tool to reach GitHub.

Once connected, Merge handles OAuth token storage and refresh on your behalf, so you never put a personal access token in your repo or manage its rotation yourself.

Related: How to use the GitHub MCP in Claude Code

Prerequisites

Before getting started, you'll need the following:

• A Merge Agent Handler account
• Codex access (available via the OpenAI platform)
• pipx installed (run pipx --version to confirm, or install via pip install pipx)
• A GitHub account with access to the repositories your tasks need

If you want to connect Merge Agent Handler's GitHub MCP with internal or customer-facing agentic products, you can follow the steps in our docs.

1. Install the Merge CLI

Install the Merge CLI with pipx: pipx install merge-api

Verify the install: merge --version

2. Log in to Merge

Run the following to authenticate the CLI with your Merge Agent Handler account: merge login

This links the CLI to your Merge account and stores your session credentials locally.

3. Add Agent Handler to Codex

From the root of the project where you want Codex to reach GitHub, run:

merge setup agents-md

This writes a Merge CLI section to your project's AGENTS.md file so Codex knows to use the CLI when a task needs GitHub data. The command is idempotent, safe to re-run if you need to reset the configuration.

Commit the updated AGENTS.md so the configuration travels with the repo.

Related: A guide to integrating the GitHub MCP with Cursor

4. Authenticate GitHub

Create a Codex task that needs live GitHub data. For example: "Read issue #482 and its full comment thread, then implement the fix in the relevant module and write a regression test."

The first time Codex invokes a GitHub tool, a Magic Link will appear to complete connector authentication.

Once authenticated, Codex can reach your GitHub account through Merge for every later task in this project.

{{this-blog-only-cta}}

GitHub MCP FAQ

In case you have more questions on setting up and using the GitHub MCP with Codex, we've addressed several more commonly-asked questions below.

What can you do once the GitHub MCP is connected to Codex?

With GitHub connected, Codex can:

• Read an issue and its full thread before implementing a fix: pull the reproduction steps, maintainer constraints, and linked references so the change it writes addresses what the issue actually describes, not a compressed summary of it

• Pull a pull request's review comments before generating a follow-up change: fetch the reviewer feedback and requested changes on an open PR so the next revision it writes resolves the comments instead of guessing at them

• Read an existing module before generating a new one beside it: retrieve the source of a similar file in the repo so the new code it generates matches the established patterns, imports, and naming

• Read a CONTRIBUTING or spec doc before scaffolding a feature: pull the repo's own conventions and design notes so the scaffold it produces follows the project's rules rather than generic defaults

• Pull related closed issues and PRs before writing tests for a bug fix: fetch how similar bugs were resolved and tested previously so the test cases it generates cover the failure modes the project has already seen

Why use Merge Agent Handler vs. a self-hosted GitHub MCP server?

You can build your own MCP server against GitHub's API. For one developer on one repo, it's straightforward: mint a personal access token, scope it, and write tool schemas for the endpoints your tasks touch.

It gets harder once more than one person uses it or tasks run in CI.

Each user needs their own token, their own scopes, and their own revocation path, and a token with broad repo access handed to an agent is a real blast radius if a task goes wrong. There's no central view of which tokens are live or what they can reach.

A self-hosted server doesn't change that. You still own token management and scoping, and now you maintain the server too. The community GitHub MCP implementations vary in endpoint coverage and upkeep, so you're betting on someone else's maintenance cadence.

Merge Agent Handler handles credential storage and token refresh across every connected user. You can scope exactly which GitHub operations a Codex task can call, and every call is logged with identity, timestamp, and inputs.

For an agent acting on your repositories, scoped access plus full audit logging is the foundation you want in place first.

Why connect GitHub to Codex?

GitHub holds the issues, pull request threads, review history, and source code that a coding task actually depends on.

Codex tasks that fix bugs, implement features, or extend a module need that context to produce a change that fits the project.

The alternative is summarizing it in the prompt, and summaries of issues and threads are always incomplete.

They drop the edge case in a buried comment, the rejected approach in a linked PR, and the convention the code follows but no one wrote down, so Codex generates a change that technically responds to the prompt but misses the project's reality.

Connecting GitHub lets Codex read the source material when a task needs it.

The full issue thread before a fix, the review comments before a revision, the neighboring module before new code: Codex works from what's actually in the repo, not a paraphrase of it.

Can I use Merge's GitHub MCP with my employees?

Yes, Merge for Workforce is built to help engineering organizations provision, secure, and govern how employees connect AI tools like Codex to development systems like GitHub.

Common patterns include:

• Provisioning and access control via SCIM with identity providers like Okta and Microsoft Entra ID, so IT can manage which repositories and organizations an employee's agent can reach by role or team

• DLP and policy enforcement on tool calls, so admins can restrict which repositories a Codex task can read and block retrieval of sensitive code or secrets before results reach the agent's context

• User-level audit logging so security and IT teams can review which issues, pull requests, and repositories were accessed, by which employee identity, and when

Put together, employees can use the GitHub MCP to implement fixes from real issue threads, generate changes that resolve actual review feedback, scaffold features that follow the repo's own conventions, and more, while IT keeps centralized control over which repositories and operations each agent can reach.