How to Use Codex with Zapier MCP
OpenAI's Codex is excellent at everything inside your repository and blind to everything outside it. Zapier MCP fixes that with one connection, 9,000+ apps, and no glue code.
What you'll get from this guide
- A working Zapier MCP server connected to Codex in about ten minutes
- The exact
codex mcp addcommands andconfig.tomlsyntax - Three production-ready workflows for Jira, monday.com, and GitHub
- The safety patterns that stop an agent from wrecking your issue tracker
Why connect Codex to Zapier MCP
Codex is OpenAI's agentic coding tool, built for engineering teams and developers who want to ship faster. It reads your codebase, writes code, runs commands, and automates development workflows from the terminal, your IDE, or the desktop app.
It is very good at everything that lives inside your repo. It knows nothing about everything outside it.
That is the gap. Your work is not only code. It is the Jira ticket that describes the bug, the monday.com board that says who owns it, the Slack thread where the decision got made, the spreadsheet tracking the migration. Codex can fix the bug in four minutes, and then you spend fifteen more updating the six places that need to know about it.
Zapier MCP closes that gap. It gives Codex a governed connection to 9,000+ apps and 30,000+ actions through a single MCP server. And if an app somehow is not in the directory, Zapier's HTTP module lets you build the integration yourself against any REST API, with no custom MCP server to write or host.
What Zapier MCP actually gives you
MCP, the Model Context Protocol, is the open standard that lets AI clients talk to external tools. Most MCP servers connect to one app. Zapier MCP is a gateway to Zapier's entire library of app connections.
Three things make it a good fit for Codex specifically.
You choose the tools
You are not handing Codex your whole SaaS stack. You pick individual actions, such as Jira: Create Issue or GitHub: Create Pull Request, and only those appear. This matters more than it sounds. A bloated tool list eats context and makes the agent worse at choosing correctly.
There are no servers to run
It is a hosted remote server over Streamable HTTP. Nothing to install, nothing to keep alive, and it follows you between machines.
One config covers every Codex surface
The Codex CLI, the IDE extension, and the desktop app share the same MCP configuration on a given machine. Set it up once.
On cost: Zapier MCP is available on all Zapier plans, and each tool call consumes Zapier tasks. Budget for that if you are planning high-volume automation.
How to connect Zapier MCP to Codex
Part 1: Build your server in Zapier
- Head to the Zapier MCP dashboard.
- Click +New MCP Server and choose Other as the client.
- Now set up your first action. Click +Add tool.
- Search for the app you want to connect to, then click its corresponding tile.
- Select whichever action events you want to connect, then click Connect.
- Connect your app accounts as needed.
- In the dashboard, configure each action according to your needs by clicking the kebab menu (⋮) and then Configure and adjusting values as needed. Hover over the tooltip icons next to any field for more details. When you are done, click Save.
- Finally, click Connect at the top of the MCP dashboard and follow the instructions to add this server to your Codex account.
Part 2: Wire it into Codex
Codex supports remote MCP servers over Streamable HTTP, with OAuth. The fastest route is the CLI:
codex mcp add zapier --url <your-server-url-from-the-dashboard>
codex mcp login zapierThe first command registers the server. The second opens a browser window so you can authorize access. Codex reuses those credentials on future sessions.
If you would rather edit config directly, add this to ~/.codex/config.toml:
[mcp_servers.zapier]
url = "<your-server-url-from-the-dashboard>"Codex picks the HTTP transport automatically when it sees a url instead of a command. There is no separate transport field.
For a server that should only be available in one repo, put the same block in .codex/config.toml inside that project. Project config only loads from directories you have marked as trusted, and user-level config wins where the two conflict.
Part 3: Verify the connection
Start a Codex session and run /mcp. You should see the Zapier server listed with the tools you enabled. You can also run codex mcp list from the terminal.
If the server shows as connected but Codex claims it has no access, that is usually the tools-only availability check quirk. Restart the session before you start debugging config.
A good sanity prompt for your first run:
List the Zapier tools you have access to and describe what each one does.
If it comes back with your Jira and GitHub actions, you are live.
Use case 1: Jira and Codex, from ticket to pull request
The problem. A bug ticket lands in Jira. You read it, hunt for the relevant code, write the fix, open a PR, then go back to Jira to update the status and paste the PR link. The coding took ten minutes. The context-switching took thirty.
Zapier tools to enable
- Jira: Find Issue
- Jira: Add Comment to Issue
- Jira: Update Issue
The prompt
Pull Jira issue PROJ-4821. Read the description and all comments, then search this repo for the code paths involved. Give me a summary of the likely root cause and a proposed fix before you change anything.
Codex fetches the ticket, cross-references it against your actual codebase, and returns a diagnosis grounded in both. That is the part you cannot get from Jira alone or from Codex alone.
Once you approve the approach:
Implement the fix, run the test suite, and if it passes, create a branch named fix/PROJ-4821. Then add a comment to PROJ-4821 explaining what changed and which files were touched, and move the issue to "In Review."
Why this works well
The ticket description is usually vague and the code is usually the truth. Codex reading both at once catches the mismatch. It will tell you when the reported behavior does not match what the code actually does, which is how a surprising number of "bugs" get resolved.
Tip: Add Jira: Find Issue with a JQL filter configured in the dashboard, and you can start the morning with "Show me every P1 assigned to me that has not moved in three days."
Use case 2: monday.com and Codex, keeping the dev board honest
The problem. Your monday.com dev board is a work of fiction by Wednesday. Items sit in "In Progress" that shipped last week. Sprint capacity gets planned against stale data. Nobody updates the board because updating the board is nobody's favorite task.
Zapier tools to enable
- monday.com: Get Item
- monday.com: Update Column Values
- monday.com: Create Item
- monday.com: Create Update
The prompt
Read my current branch and the last 20 commits. For each commit that references a monday.com item ID, check that item's current status. Show me a table of item ID, board status, and what the commits suggest the real status is. Flag any mismatches. Do not update anything yet.
You get a reconciliation report between what your board claims and what your git history proves. Then:
Update the four mismatched items to their correct status and post an update on each one summarizing the commits that moved it forward.
Running it in the other direction
Instead of code updating the board, let the board scope the code:
Get item 7742119 from the Dev board, including all column values and updates. Based on the description and acceptance criteria, tell me which files in this repo would need to change, roughly how much work it is, and what could go wrong. Then create a subitem for each distinct piece of work.
This turns a one-line board item into a real technical breakdown, informed by your actual repo rather than a guess. It is the most useful thing you can do at sprint planning.
Tip: monday.com column values are structured and fussy about format. Configure the exact column IDs in the Zapier dashboard rather than hoping Codex infers them. The tooltips tell you what each field expects.
Use case 3: GitHub and Codex, release notes and backlog triage
You might reasonably ask why you would route GitHub through Zapier when Codex already has git access locally. The answer is that local git gives Codex your working copy. It does not give it the review state, the issue backlog, the CI results, or the discussion threads. Zapier's GitHub actions do.
Zapier tools to enable
- GitHub: Find Pull Request
- GitHub: Create Issue
- GitHub: Create Comment
- GitHub: Update Issue
- GitHub: Create Release
Writing release notes
Diff the current branch against the last release tag. For every merged PR in that range, fetch its title, description, and labels from GitHub. Write release notes grouped into Features, Fixes, and Breaking Changes, written for users rather than engineers. Skip anything labeled internal or chore. Show me the draft first.
The reason to have it read the pull requests rather than the commit messages: commit messages are for you, PR descriptions are for other people. The second set produces notes an actual customer can read.
Triaging a stale backlog
Fetch open issues in this repo labeled bug with no activity in 30 days. For each one, search the codebase and tell me whether it looks already fixed, still valid, or unreproducible from the description. Post a comment on the ones that appear fixed asking the reporter to confirm, and close nothing without asking me.
Stale bug backlogs are almost always 40% already-fixed. This is a genuinely tedious job that Codex does well, because deciding whether an issue is still live requires reading both the issue and the code.
The safety pattern: every prompt above ends with an explicit boundary. Show me the draft first. Close nothing without asking me. Do not update anything yet. Use these. Codex is capable and fast, and both of those qualities cut both ways when it has write access to your issue tracker.
Getting more out of it
Keep the tool list lean
Enable the specific actions you will actually use, not every action an app supports. Ten well-chosen tools beat sixty. Fewer tools means less context consumed and better tool-selection accuracy.
Use separate MCP servers for separate jobs
One server with your ticketing tools, another with your comms tools. Point Codex at whichever fits the task. Project-scoped config in .codex/config.toml is useful here.
Read before you write
For any workflow, run the read-only version first. Confirm Codex is fetching the right records before you let it update them.
Reach for the HTTP module when an app is missing
Zapier's HTTP action lets you hit any REST endpoint. That covers your internal admin API, a niche vendor tool, or anything not in the directory. You configure the request in the Zapier dashboard, and Codex calls it like any other tool.
Put standing instructions in AGENTS.md
If you always want Jira comments in a particular format, or always want the board updated after a merge, write it in your repo's AGENTS.md file rather than typing it into every prompt.
Frequently asked questions
Does Codex support remote MCP servers?
Yes. Codex supports both local STDIO servers and remote Streamable HTTP servers, with OAuth, bearer tokens, or custom headers. You add a url instead of a command and Codex selects the HTTP transport automatically.
Where is the Codex MCP config file?
User-level servers live in ~/.codex/config.toml. Project-scoped servers go in .codex/config.toml inside the repo, and only load from trusted directories. Where the two conflict, user-level config wins.
Do I need to edit config.toml by hand?
No. The codex mcp add command writes the same configuration for you, and writes are atomic, so a failed add will not leave you with a half-written config file. Hand-editing is useful mainly for scripting or for the few options the CLI does not expose.
How much does Zapier MCP cost?
The Codex side is free, since MCP support is built in. Zapier MCP is available on all Zapier plans, and each tool call consumes Zapier tasks, so cost scales with how many actions your agent takes.
What if the app I need is not on Zapier?
Use Zapier's HTTP module to build the integration against the service's REST API. You configure the request in the Zapier dashboard and Codex calls it like any other tool, with no custom MCP server to write or host.
Can I use the same Zapier MCP server with other AI clients?
Yes. That is the point of remote MCP. The same endpoint works from Codex, Claude, Cursor, ChatGPT, or any other client that supports the Model Context Protocol.
Wrapping up
The three workflows above are a starting point, not a limit. Once Codex can reach your ticketing system, your project board, and your repo host in the same session, the interesting prompts are the ones that cross all three at once. Read the ticket, check the board, search the code, write the fix, update everything.
That is the part that used to be glue code and browser tabs. Now it is a sentence.