Levi Gans
Add Interfere’s MCP server to Codex with one command or the plugin, investigate a production bug from your terminal, then save the fix as a skill your team can reuse.
Codex reads your repository, runs your tests and edits files, but it can’t see production. It doesn’t know which error users started hitting after Tuesday’s deploy or whether last week’s fix stopped it. Interfere is an AI tool for production bugs. It groups errors into problems, works out the cause from stack traces and session replays, and tracks whether a fix held. Over MCP, Codex reads all of it with your Interfere permissions.
Before you start, have:
- Codex (the CLI, the IDE extension or the ChatGPT desktop app), opened in the repository the bugs live in
- An Interfere workspace receiving events from that app, with source maps uploaded (get started)
- The repository connected to Interfere through GitHub, so investigations cite real files and commits
- Codex able to open pull requests in that repository, for example with the GitHub CLI
What an MCP server adds to Codex
Without one, Codex only knows what you paste into the chat:
| Codex wants to know | Pasted into the chat | Read through Interfere’s MCP server |
|---|---|---|
| Which error to fix first | Whatever you noticed | Problems ranked by priority, with affected users |
| Where the code fails | A minified stack trace | Stack frames mapped to source through your source maps |
| When it started | Nobody knows | First seen, matched to the release that shipped it |
| What the user did | One customer’s account of it | A replay of the session up to the error |
| Whether the fix held | Someone checks by hand | In recovery, then Resolved, or reopened as a regression |
Add Interfere’s MCP server to Codex
Both options sign in through OAuth in your browser, so no API key ends up in a config file. The Codex CLI, the IDE extension and the ChatGPT desktop app share one configuration, so you only connect once.
Install the Interfere plugin
Run these in your terminal, then restart your Codex session and finish the Interfere sign-in when it asks:
1codex plugin marketplace add https://github.com/interfere-inc/plugins.git2codex plugin add interfere@interfere-plugin-marketplace
The plugin also adds setup and investigation skills. It connects to https://mcp.interfere.com/mcp, which can change workspace data within your permissions.
Add the server with codex mcp add
1codex mcp add interfere --url https://mcp.interfere.com/mcp/readonlyCodex detects that Interfere uses OAuth and opens the sign-in in your browser. If it doesn’t, run codex mcp login interfere.
The command saves the server to ~/.codex/config.toml, so it works in every repository. To share it with your team instead, commit the same entry to .codex/config.toml in the repository. Codex only reads that file in trusted projects:
1[mcp_servers.interfere]2url = "https://mcp.interfere.com/mcp/readonly"
The read-only endpoint rejects any change to workspace data, so Codex can investigate without moving a problem’s status. Run /mcp in Codex to check that interfere is listed. The MCP docs cover other clients.
Investigate a production bug from Codex
For the first run, pick a problem you already understand so you can judge the answer:
1Using Interfere, open this problem: <problem link>2Which release did it start in, how many users hit it, and which stack frame3fails? Show me the code at that frame in this repo before suggesting a change.
If the investigation already suggests a fix, the problem’s timeline shows Fix ready with a Copy prompt button. Paste that prompt into Codex instead.
Either way, check the diff against the evidence. The change should touch the failing code path, and a test should fail without it.
Write the fix down as a skill
Once a few manual fixes look like ones you’d merge, save the steps as a skill. Codex reads skills from .agents/skills in your repository. Create .agents/skills/interfere-fix/SKILL.md:
1---2name: interfere-fix3description: Fix an Interfere problem using the Interfere MCP, with a regression test and a draft pull request. Use when given an Interfere problem link.4---56Fix the Interfere problem I link using the Interfere MCP.781. If the Interfere MCP server is not connected yet, stop and ask me to run9 `codex mcp login interfere`.102. Look for an open pull request whose description contains this problem's11 Interfere link. If there is one, stop.123. Use the Interfere MCP to read the problem in the workspace from the link:13 its root cause, the evidence and the suggested fix. Search the MCP for14 these operation IDs: problems_get, problemEvidence, problemSource,15 problemRelated, problemImpact, findingOccurrences, traceLogs. Read at16 least two occurrences and their logs before you change code.174. If the cause is outside this repository, such as an expired key, a18 provider outage or an infrastructure setting, summarize it and stop.195. Write a test that reproduces the failure. It must fail before your change20 and pass after it.216. Apply the fix in this repository, adapting it if the code has moved22 since. Change only the code the fix needs, then run the full test suite.237. Open a draft pull request. Put the Interfere problem link on the first24 line of the description, then the cause in one sentence and the test25 command. A person merges it. You don't.268. Summarize what you changed and link the pull request.
Commit it, and run it by typing $interfere-fix with a problem link, or pick it from /skills. The duplicate check looks at open pull requests, which every teammate can see, so a later run on the same problem stops instead of opening another one.
Check the fix in production
After the deploy, the problem moves to In recovery while Interfere looks for new occurrences, then to Resolved once they stop. If the error comes back, it reopens as a regression with its original first-seen date. Once a week, ask Codex:
1Find pull requests merged in the last 7 days that link an Interfere problem.2For each one, give the problem's current status and flag any that are still3Active or have reopened as a regression.
Review flagged pull requests first, since the bug they targeted is still happening. The MTTR guide shows where this saves time.
Troubleshooting
| What happens | What to do |
|---|---|
/mcp doesn’t list interfere | Restart Codex. If you used .codex/config.toml, trust the project, or add it globally. |
| Interfere tools fail with a sign-in error | Run codex mcp login interfere and finish the sign-in in your browser. |
| Interfere refuses to change a problem’s status | You’re on /mcp/readonly, which rejects writes. Use /mcp only for intended changes. |
| A large investigation times out | Codex waits 60 seconds per tool call. Set tool_timeout_sec higher under the server. |
| Two pull requests open for the same problem | Make sure each description has the problem link. The duplicate check searches for it. |
Does Codex support remote MCP servers?
Yes. codex mcp add with --url registers a streamable HTTP server, and codex mcp login handles the OAuth sign-in. Nothing runs on your machine for a remote server like Interfere’s.
Codex vs Claude Code for fixing production bugs
Both read the same Interfere investigation and commit their skills to the repository, so the whole team runs the same steps. Codex keeps servers in config.toml and skills in .agents/skills, and you call a skill with $. Claude Code uses claude mcp add and .claude/skills, as the Claude Code guide shows. For fixes on a schedule, see the Grok Bot guide.
Set up Interfere, connect it to Codex, and try it on one problem you already understand.