# Connect Elaichi to Codex > To connect Elaichi to Codex, add one URL as a streamable HTTP server and run codex mcp login. No token, no header, and each engineer signs in as themselves. **TL;DR** To connect Elaichi to Codex, add https://api.elaichi.ai/mcp as a streamable HTTP MCP server, with codex mcp add or in config.toml, then run codex mcp login and finish the sign-in in a browser. The entry holds a URL and no secret, and the Codex CLI, the IDE extension and the ChatGPT desktop app share it. After sign-in, the engineer's Elaichi role, what is shared with them and any restrictions decide which Jira, Slack and other tools Codex can call. Codex is OpenAI's coding agent. It runs in a terminal, in an editor and in the ChatGPT desktop app. Hand it a bug, and it wants the Jira issue, the Sentry error and the Slack thread. Each of those needs a credential. The quick fix is a personal token in an environment variable, one per app, per engineer. One endpoint behind OAuth replaces those tokens. ## How do you connect Elaichi to Codex? Add Elaichi's endpoint, `https://api.elaichi.ai/mcp`, to Codex as a streamable HTTP server, then run `codex mcp login elaichi` and sign in in the browser. There is no API key, no header and no server to run. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Its [specification](https://modelcontextprotocol.io/specification/2026-07-28) is public. Elaichi serves every connected SaaS account at one organization-wide address, behind OAuth (a sign-in that issues a revocable grant instead of a copied secret). ## Which Codex command adds the Elaichi endpoint? `codex mcp add` with a name and `--url`. OpenAI's command reference says `add` registers "a server using a stdio launcher command or a streamable HTTP URL" ([Codex command line options](https://learn.chatgpt.com/docs/developer-commands?surface=cli), checked October 2026). For Elaichi: ```bash codex mcp add elaichi --url https://api.elaichi.ai/mcp ``` Leave out `--bearer-token-env-var` and `--oauth-client-id`. Elaichi takes no pasted token and needs no client ID. Copy the URL exactly, with no trailing slash and on the `api` host. With a trailing slash the endpoint returns 404, and on `app.elaichi.ai` it returns 405. Neither starts sign-in. ## How do you add Elaichi in config.toml or the IDE extension? Write one `[mcp_servers.elaichi]` table, or use the extension's form. Codex keeps MCP servers in `~/.codex/config.toml`, and a project can scope one in `.codex/config.toml`, for trusted projects only ([Codex MCP docs](https://learn.chatgpt.com/docs/extend/mcp?surface=cli), checked October 2026). The entry is two lines: ```toml [mcp_servers.elaichi] url = "https://api.elaichi.ai/mcp" ``` The docs say the ChatGPT desktop app, the Codex CLI and the IDE extension share this configuration. Add Elaichi once, and all three see it. In the IDE extension, open the gear menu, then **MCP servers**, then **Add server**. Enter `elaichi`, choose **Streamable HTTP**, paste the URL, save, and select **Restart extension**. The list then marks servers that need OAuth, and **Authenticate** starts the sign-in. A project file holding only this entry is safe to commit, because it carries no secret. Every clone gets the same address, and each engineer still signs in as themselves. ## What happens when you run codex mcp login? Codex opens Elaichi's sign-in in the browser, and the engineer approves a consent screen. OpenAI's docs say to run `codex mcp login ` "to start an MCP OAuth login". Without it, Codex can connect with no credential at all, and Elaichi answers that request with a sign-in challenge. Codex registers itself through dynamic client registration ([RFC 7591](https://www.rfc-editor.org/rfc/rfc7591)), which Elaichi supports, so there is no client ID to enter. Its callback listens on `127.0.0.1`. Elaichi checks the callback address exactly, except that a loopback address may change its port. [RFC 8252](https://www.rfc-editor.org/rfc/rfc8252#section-7.3) sets that rule for native apps. Codex asks for the scopes the server advertises, and Elaichi advertises all of its MCP scopes. The consent screen still holds deletes back. The engineer picks one organization, then sees up to four boxes: read data, create and change data, run connected tools, and delete data. Everything requested starts ticked except delete. Keep **Run your connected tools** ticked, or Codex reaches no connected app. The request lasts 30 minutes and works once. Sign-in needs a browser. Codex running headless in CI, or in a terminal with no browser access, cannot complete Elaichi's sign-in. Sign in from a machine where the engineer can open a browser. ## How do you check that Codex can see Elaichi's tools? List the server, then ask for one read. `codex mcp list` shows configured servers, and `codex mcp get elaichi` shows one entry. Inside the `codex` TUI, `/mcp` shows the active servers. Expect a short tool list. In Elaichi, connected tools are never listed one by one, however few there are. Codex calls `search_tools` to find a connected tool, then `execute_tool` to run it. Those two, plus any Elaichi operations the engineer's role and grant allow, make up the list. Then ask a real question, such as "Summarize my open Jira issues". If the list is empty or an app is missing, [the missing-tools checklist](/blog/mcp-tools-not-showing/) walks the causes in order. ## Which Codex approval setting fits Elaichi? Use Codex's settings for prompts, and Elaichi's restrictions for what Codex may reach. Codex sets approvals per server with `default_tools_approval_mode`, which takes `auto`, `prompt`, `writes` or `approve`. The docs say `writes` "prompts for tools that aren't marked read-only". Elaichi marks `search_tools` read-only and marks `execute_tool` as destructive, because its real effect depends on the tool it runs. Under `writes`, a search runs freely, and every call into a connected app prompts, reads included. Codex's `enabled_tools` and `disabled_tools` lists name tools too. Every connected Elaichi tool arrives through `execute_tool`, so those lists cannot tell a Jira read from a Jira delete. Elaichi's restrictions can, and they bind whichever client the engineer uses. ## What do roles, restrictions and the audit log add for Codex? Elaichi checks every Codex call against the engineer's role, shares and restrictions, whatever approval mode Codex runs in. The role must carry `tool:execute`, which gates the whole endpoint. Restrictions decide which connectors and which individual tools a target may reach. A restricted tool never appears in search, so Codex finds nothing to call. A role or restriction change takes about two minutes to apply. The audit trail writes one entry per tool-call attempt, succeeded or failed, under the engineer who signed in, naming the account the call reached. It keeps argument names and counts, and never argument values. Each entry also records the OAuth client. Codex CLI signs in through a loopback address, so the trail shows the name Codex registered with, marked unverified. [MCP for coding agents across an engineering org](/blog/coding-agents-company-tools/) covers frozen arguments and the rest of the case. ## Which MCP gateway works with both Codex and Claude Code? Elaichi does, because both clients speak the same remote MCP and the same OAuth sign-in. An engineering team adds one address to each agent, and one set of rules covers both. That address is the one the rest of the company uses. Clients point at it and sign in: Claude, ChatGPT, Cursor, any MCP client, and the Elaichi Agent. The setup differs per client, not the URL. [The Claude Code setup](/blog/connect-elaichi-to-claude-code/) and [the ChatGPT setup](/blog/connect-elaichi-to-chatgpt/) use it unchanged. ## Where do Jira, Slack and GitHub fit in a Codex setup? Jira and Slack go through Elaichi, and GitHub does not. An admin or engineer connects each SaaS account once, from a catalog of 500+ connectors that Elaichi authors and serves. A separate credential service holds each account's secrets, encrypted at rest, so no Jira or Slack token sits in an environment variable. [Replacing personal MCP servers on laptops](/blog/replace-personal-mcp-servers/) covers the cleanup of tokens already out there. No shared service account is needed. Each engineer's own grant authorizes their calls, and the audit trail names them. A shared Jira connection still reaches Jira as the account that connected it. Where Jira's own permissions must be the engineer's, each engineer connects their own account. The [Jira connector](/connectors/jira/) and the [Slack connector](/connectors/slack/) list every tool a rule can name. GitHub is not in Elaichi's [connector catalog](/connectors/). [GitHub's guide for Codex](https://github.com/github/github-mcp-server/blob/main/docs/installation-guides/install-codex.md) (checked October 2026) adds GitHub's own server with a personal access token in `bearer_token_env_var`. Calls to it skip Elaichi's restrictions and audit trail. ## What goes wrong when Codex connects to Elaichi? Most failures are the URL, an expired request or a missing checkbox. Each has a quick fix: - **Sign-in never starts.** Check the URL for a trailing slash or the `app` host. With no browser, sign-in cannot finish. - **The consent screen says the request is no longer valid.** It expired or was used. Run `codex mcp login elaichi` again. - **A tool error names a checkbox.** Run `codex mcp logout elaichi`, then log in again and tick the box. - **The list is empty for a whole role.** The role may lack `tool:execute`, which an admin fixes. - **A 429 mid-task.** Elaichi allows 120 MCP requests a minute per token. Wait a minute. [What each OAuth error means](/blog/mcp-oauth-errors/) covers the rest, with who fixes each one. ## How do you disconnect Codex from Elaichi? Log out in Codex, then end the grant in Elaichi. `codex mcp logout elaichi` removes the OAuth credentials Codex stored for the server. To be sure the grant has ended, disconnect it in Elaichi under **Settings**, then **Connected apps**. When an admin removes or suspends a member, removing or suspending a member revokes every live grant in the same transaction as the membership change, so that engineer's next Codex call fails. ## When does a Codex user not need Elaichi? When one engineer uses Codex against one app they own. That app's own MCP server, signed in with OAuth, is enough. Revisit when a second app arrives, a contractor joins, or someone asks which agent changed a ticket. [When you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) lists the signals. Gold lists at $15 per user per month in USD, and the [pricing page](/pricing/) shows your region's price. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. For the wider picture, read [what an MCP control plane is](/blog/what-is-an-mcp-control-plane/). ## FAQ ### Is there an MCP gateway that supports Claude Code and Codex for engineering teams? Elaichi serves one organization-wide MCP endpoint over Streamable HTTP behind OAuth, and both Claude Code and Codex connect to it. Each engineer adds https://api.elaichi.ai/mcp once and signs in as themselves. Roles, restrictions and one audit trail then apply to both agents, because both reach company apps through the same address. ### Does one MCP server URL work in Claude, ChatGPT, Cursor, Claude Code and Codex? Yes, with Elaichi. Its endpoint, https://api.elaichi.ai/mcp, is the same for every client and every member of the organization. Each client adds it once, and each person signs in with their own OAuth grant. The address never changes, and only the grant behind it differs. ### How do you give Codex access to SaaS apps without a shared service account? Point Codex at one endpoint that each engineer signs in to with their own OAuth grant. With Elaichi, that grant authorizes every call, the audit trail names the engineer, and removing the engineer ends the grant without touching anyone else. Where the app itself must see the engineer, each engineer connects their own account once. ### Can Codex use Elaichi in CI? Not unattended. Elaichi's sign-in needs a browser, so a Codex run in CI or in a terminal with no access to a browser cannot complete it. Engineers sign in on their own machines, where a browser can open. ### Is it safe to commit an Elaichi entry to .codex/config.toml? Yes. The entry holds a public URL and nothing else: no token, no header and no client secret. Codex reads a project's .codex/config.toml only in trusted projects, and each engineer still signs in as themselves. ## Read next - [Connect Elaichi to Claude Code](/blog/connect-elaichi-to-claude-code/) — To connect Elaichi to Claude Code, run one claude mcp add command and sign in with OAuth. The entry holds no secret, so a project .mcp.json is safe to commit. - [MCP for coding agents across an engineering org](/blog/coding-agents-company-tools/) — MCP for coding agents needs one endpoint, a sign-in per engineer, and rules the agent cannot edit, because nobody reads each call it makes. - [Fix OAuth errors when adding an MCP connector](/blog/mcp-oauth-errors/) — Most OAuth errors when adding an MCP connector come from the URL, the account or a missing checkbox. What each Elaichi error means, and who fixes it.