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 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, checked October 2026). For Elaichi:
codex mcp add elaichi --url https://api.elaichi.ai/mcpLeave 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, checked October 2026). The entry is two lines:
[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 <server-name> "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), 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 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 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 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 and the ChatGPT setup 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 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 and the Slack connector list every tool a rule can name.
GitHub is not in Elaichi's connector catalog. GitHub's guide for Codex (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
apphost. 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 elaichiagain. - 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 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 lists the signals.
Gold lists at $15 per user per month in USD, and the pricing page 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.
