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

When you hand Codex a task to build a Salesforce sync or integration, you usually describe the objects and fields in the prompt.

That description isn't enough. Custom objects and fields carry org-specific API names ending in __c, picklists hold values configured per org, and standard objects relate to each other in ways that vary by setup.

Codex will, as a result, write SOQL against a field that doesn't exist, validation that misses half the real picklist values, or relationship queries that don't match your schema.

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

How it works

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

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

Related: How to use the Salesforce 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 Salesforce account with API access to the objects your tasks need

If you want to connect Merge Agent Handler's Salesforce 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 Salesforce, 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 Salesforce 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 Salesforce MCP with Cursor

4. Authenticate Salesforce

Create a Codex task that needs live Salesforce data. For instance: "Read the Opportunity object's fields, including custom fields and the Stage picklist values, then scaffold a sync that maps Opportunities into our internal schema."

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

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

{{this-blog-only-cta}}

Salesforce MCP FAQ

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

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

With Salesforce connected, Codex can:

• Read an object's real field list, including custom fields, before scaffolding a sync: pull the actual API names so the SOQL and mapping code it generates targets fields that exist in your org, not guessed names without the __c suffix

• Pull picklist values before generating validation logic: fetch the real options for Stage, Status, or LeadSource so the validation and mapping code it writes covers every value the org actually uses

• Read a real record before generating deserialization code: fetch an actual Opportunity, Account, or Contact so the parsing it produces matches the field values and types the API really returns

• Inspect relationship structure before generating SOQL: retrieve how objects relate, such as Accounts to Contacts or Opportunities to Tasks, so the relationship queries it writes are correct and avoid N+1 patterns

• Pull real records before generating test fixtures: fetch live records so the fixtures and assertions it produces reflect the data shape the integration will actually run against

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

You can build your own MCP server on top of the Salesforce API. For one developer on one org, it's workable: set up a connected app, run the OAuth flow, 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 and refresh cycle, and a Salesforce token carries the full access of its profile, so handing it to an agent without scoping gives that agent broad reach across your CRM. 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 the OAuth plumbing and the connected app, and now you maintain the server too. Community Salesforce MCP builds vary in object coverage and upkeep, so you're betting on someone else's maintenance.

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

For an agent acting on CRM data that drives revenue operations, scoped access plus full audit logging is the foundation you want in place first.

Why connect Salesforce to Codex?

Salesforce holds the object schemas, custom field API names, picklist values, and relationship layouts that CRM integration code has to match exactly.

Codex tasks that write syncs, validation logic, or reporting features need that ground truth to produce code that runs against your org.

The alternative is describing the schema in the prompt, and those descriptions are always a little wrong. A custom field missing its __c suffix, an out-of-date picklist, or a misremembered relationship is enough to make Codex generate SOQL that errors or code that drops data.

Connecting Salesforce lets Codex read the actual schema when a task needs it. The object's fields before a sync, the picklist values before validation, a real record before deserialization: Codex works from your org, not a paraphrase of it.

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

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

Common patterns include:

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

• DLP and policy enforcement on tool calls, so admins can block queries that would return sensitive account or contact data before results reach a Codex task's context

• User-level audit logging so security and IT teams can review which objects and records were accessed, by which employee identity, and when

Taken together, employees can use the Salesforce MCP to scaffold syncs against real object schemas, generate validation logic from actual picklist values, and write relationship queries that match the org's layout, and more, while IT keeps centralized control over which objects each agent can reach.