LIVE|CLI v0.144.0·model GPT-5.6 Sol·verified 2026-07-09
Codex Insider
The unofficial wire for OpenAI Codex.
Ecosystem

Connect Codex to Sentry

Published Jul 16, 2026 · Checked against the official docs

The short version

You'll end up on Sentry's hosted MCP server by default — the local stdio option is only for self-hosted installs, and it's officially still unfinished. Once you're in, plain-English search across issues and events needs its own LLM key (OpenAI, Azure OpenAI, Anthropic, or OpenRouter), or those two tools just won't show up. Everything else works without it.

What you get

Sentry’s MCP server sits between Codex and the Sentry API. Sentry’s README describes the service as “primarily designed for human-in-the-loop coding agents,” with tool selection “focused on developer workflows and debugging use cases, rather than providing a general-purpose MCP server for all Sentry functionality.”

The README does not publish a full tool list, so this page won’t invent one. It names three tools directly. search_events and search_issues are the AI-powered search tools that translate plain English into Sentry’s query syntax, and use_sentry is what the repo’s own CLI notes call agent mode. Those two search tools need an LLM provider configured (OpenAI, Azure OpenAI, Anthropic, or OpenRouter). Without one, the README says “these specific tools will be unavailable, but all other tools will function normally.”

Sentry also groups tools into “skills.” The README’s examples name inspect, triage, and seer, and it doesn’t publish the full set. You can narrow what the remote endpoint exposes with a query string like ?skills=inspect,triage or ?disable-skills=seer, on top of whatever enabled_tools or disabled_tools you set on Codex’s side.

Setup

Read Connect an MCP server first for the general TOML shape. If you haven’t installed the CLI yet, start at Install Codex CLI.

Sentry’s README points you at the hosted service first (“You’ll find everything you need to know by visiting the deployed service in production”) and calls the stdio transport “still a work in progress,” useful mainly for self-hosted Sentry. Default to remote unless you’re running self-hosted.

  1. Remote, OAuth (default path). Add this to ~/.codex/config.toml:
[mcp_servers.sentry]
url = "https://mcp.sentry.dev/mcp"

Run codex mcp login sentry. That opens a browser, runs the OAuth flow, and Codex catches the callback locally. Confirm it initialized with codex mcp list.

  1. Stdio (self-hosted Sentry, or a direct token instead of OAuth). The package is @sentry/mcp-server, published by Sentry, at 0.37.0 as of 2026-07-02. Use the one-liner:
codex mcp add sentry --env SENTRY_ACCESS_TOKEN=your-token -- npx -y @sentry/mcp-server@latest

--env is documented and writes the env sub-table for you, but a token typed on the command line lands in your shell history. To keep it out, write the block by hand instead:

[mcp_servers.sentry]
command = "npx"
args = ["-y", "@sentry/mcp-server@latest"]
startup_timeout_sec = 30

[mcp_servers.sentry.env]
SENTRY_ACCESS_TOKEN = "your-sentry-user-auth-token"

You’ll be editing config.toml anyway if you want startup_timeout_sec, since codex mcp add doesn’t write it. Create the token under Sentry’s User Auth Token settings. The README lists six scopes as of writing: org:read, project:read, project:write, team:read, team:write, event:write. Put the token in the env sub-table, not inline in args. See mcp_servers.<id>.env for why that matters. Confirm with codex mcp list.

  1. Self-hosted Sentry. Add SENTRY_HOST = "sentry.example.com" to the same env sub-table, hostname only. That’s how Sentry’s own client-config example handles it. The README notes Seer may not exist on self-hosted, so add MCP_DISABLE_SKILLS = "seer" alongside it to stop unsupported tools from being exposed.

  2. Natural-language search tools. search_events and search_issues need an LLM provider. Add to the env sub-table:

EMBEDDED_AGENT_PROVIDER = "anthropic"
ANTHROPIC_API_KEY = "sk-ant-..."

Sentry’s README is blunt about naming the provider explicitly: “Auto-detection based on API keys alone is deprecated and will be removed in a future release.” Skip this whole step and every other tool still works.

Gotchas

Skip the mcp-remote shim. A widely-circulated Medium walkthrough by Lamine Niasse (November 2025) wires Sentry into Codex as a local process: command = "npx", args = ["-y", "mcp-remote@latest", "https://mcp.sentry.dev/mcp", "--access-token=<TOKEN>", ...]. That pipes the remote endpoint through a stdio bridge and types the token straight into args. Codex speaks streamable HTTP natively, which is what url = is for, so the bridge does nothing for you here. It’s also its own cold-npx download, hitting the same 10-second startup_timeout_sec default covered below. A token sitting in args also shows up in your process list, and it gets committed to config.toml in plaintext if that file is ever checked in. Use url = with codex mcp login, or the stdio env sub-table above, rather than putting --access-token= on a command line Codex will store.

Cold npx eats the 10-second window. First run downloads @sentry/mcp-server before it can answer Codex’s handshake, so raise startup_timeout_sec past its documented default of 10 (30 is plenty). openai/codex #6020 reports something more severe on codex-cli 0.53.0: one malformed server entry can take every configured server down at once, not just the broken one. Still open as of this writing. If Sentry fails alongside servers that were working before, disable entries one at a time to isolate it.

/sse is not what the README documents. We read the current getsentry/sentry-mcp README directly and grepped it. It names https://mcp.sentry.dev/mcp, and the string sse appears nowhere in it. Treat any /sse example you find elsewhere as stale.

docs.sentry.io/product/sentry-mcp/ 301-redirects to mcp.sentry.dev, which is a client-rendered app. Fetching it returns a 2KB empty shell, not documentation. The GitHub README is the real source for setup details, and it’s what this page is built from.

We could not confirm the header-token path for Codex. Sentry’s README documents a second remote option: pass the token as an Authorization: Sentry-Bearer <token> header, which it says is deliberately separate from the standard scheme because “Bearer is reserved for MCP OAuth access tokens.” Codex’s config reference lists bearer_token_env_var for bearer-style remote auth but never documents what scheme it emits, so nothing confirms it sends Sentry-Bearer instead of plain Bearer. Until someone verifies it, use OAuth login or the stdio token path above.

Sources