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

Support teams document real bugs, edge cases, and customer pain points in Zendesk tickets. When developers create Codex tasks to fix those bugs or build features, they summarize the ticket.

That summary loses the specific error messages, reproduction steps, and customer context that the ticket actually contains.

Codex writes code against what the developer described, not against what the ticket actually says. The result is fixes that address a general interpretation of the problem rather than the specific conditions the customer reported.

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

How it works

Merge Agent Handler connects Codex to the Zendesk 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 Zendesk.

Once connected, Merge handles OAuth token storage and refresh on your behalf, so you never embed credentials in your repo or manage rotation yourself.

Related: How to use the Zendesk 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 Zendesk account with permission to authenticate the connector

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

1. Install the Merge CLI

Install the CLI with pipx: pipx install merge-api

Verify it installed correctly: merge --version

2. Log in to Merge

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 have access to Zendesk, 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 requires Zendesk data. The command is idempotent, safe to re-run if you need to reset the configuration.

Commit the updated AGENTS.md so every developer and CI environment that runs Codex gets the same tool configuration.

Related: A guide to integrating the Zendesk MCP with Cursor

4. Authenticate Zendesk

Create a Codex task that requires live Zendesk data. For example: "Read the three most recent tickets tagged 'checkout-error' and generate a bug fix for the underlying issue, including a regression test."

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

Once authenticated, Codex has access to your Zendesk account through Merge for all subsequent tasks in this project.

{{this-blog-only-cta}}

Zendesk MCP FAQ

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

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

With Zendesk connected, Codex can:

• Read a customer incident report before generating a fix: pull the actual ticket, including the full description and comment thread, so the generated fix addresses the specific error conditions and reproduction steps the customer reported, not a developer's summary of them

• Pull ticket history to understand recurring bug patterns before generating error handling code: retrieve a set of related tickets over time to identify which edge cases have appeared repeatedly, then use that pattern to generate handling logic that covers the real failure modes

• Read macro and trigger configurations to generate corresponding automation code: fetch the macros and triggers your support team has already defined in Zendesk so any automation code Codex generates matches the actual business logic those configurations encode

• Pull internal notes to generate accurate issue documentation: retrieve the internal notes engineers and support agents have added to a ticket to produce issue summaries or runbooks that reflect the diagnosis and context that's already been recorded, rather than reconstructing it from scratch

• Read linked ticket chains to generate code that covers escalation paths: fetch a parent ticket and its related follow-up tickets to understand how an issue evolved, then generate code that handles the full lifecycle of that issue type

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

You can build a self-hosted Zendesk MCP server that calls Zendesk's REST API directly. For a single developer, that's workable: generate an API token, write tool schemas for the endpoints you need, and wire it into Codex.

The self-hosted path breaks down at the team level.

Zendesk API tokens are per-user, so every developer manages their own token. There's no central place to scope which ticket data or operations a Codex task is allowed to access, no audit trail of what the agent read or modified, and no clean revocation path when someone leaves the team.

Merge Agent Handler adds a managed layer: credential storage and OAuth refresh handled by Merge, per-user access scoping so each developer authenticates with their own identity, and full audit logging on every tool call.

For teams using Codex on production codebases where Zendesk tickets contain customer PII or sensitive internal notes, that observability matters.

Why connect Zendesk to Codex?

Most engineering teams rely on Zendesk tickets as the primary record of what's broken, what customers have reported, and what support agents have already tried. Codex doesn't have access to any of that unless a developer manually copies it into the task description.

That copy step is always lossy. Developers paraphrase, omit reproduction steps, and leave out the internal notes where the real diagnostic work happened. Codex writes against the paraphrase, not the source.

Connecting Zendesk gives Codex the ability to pull the source ticket directly when a task requires it. The incident report for the bug being fixed, the ticket thread that documents a recurring failure pattern, the macro definition that a new automation needs to match: Codex reads the original rather than the developer's interpretation of it.

The output reflects what the tickets actually document. That closes the gap between what support teams observed and what gets built to address it.

Can I use Merge's Zendesk 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 customer support systems like Zendesk.

Common patterns include:

• Provisioning and access control via SCIM with identity providers like Okta and Microsoft Entra ID, so IT can manage which employees can access which ticket queues, organizations, and Zendesk views by role or team

• DLP and policy enforcement on tool calls, so admins can block Codex tasks from reading tickets outside their designated project scope or prevent retrieval of customer PII before it reaches the agent's context

• User-level audit logging so security and IT teams can review which tickets were read, which ticket threads were retrieved, and which Zendesk data was accessed, by which employee identity, and when

Taken together, employees can use the Zendesk MCP to generate bug fixes grounded in real incident data, produce documentation from actual ticket history, and build automation code that matches live trigger and macro configurations, while IT keeps centralized control over which queues and data each developer's agent can reach.