Give Codex an email inbox

Codex runs long, mostly unattended. That is exactly the shape of work where email matters: something finishes, something fails, somebody replies, and the agent is the one who should notice.

Anjal gives it an inbox. Two commands.

Connect it

codex mcp add anjal --url https://mcp.anjal.app/mcp
codex mcp login anjal

login opens a browser on Anjal. Sign in, review what Codex will be able to do, click Allow, and the token is stored by Codex. Unlike a bearer token in an env var, there is no secret for you to hold, rotate or leak.

If you would rather write the config by hand, it lives in ~/.codex/config.toml (or .codex/config.toml in the project):

[mcp_servers.anjal]
url = "https://mcp.anjal.app/mcp"
auth = "oauth"

Then run codex mcp login anjal as above.

What Codex gets

47 tools across inboxes, messages, threads, drafts, attachments, domains, workspaces, webhooks and calendar. The ones that matter for unattended work:

What this is actually for

The agent reports in. A long Codex run that ends at 2am can send you the summary itself, from an address you can reply to, and then read your reply on the next run. That is a better loop than a log file you have to go and find.

It gets past signup walls on its own. Integrating a third-party API usually means creating an account on it. With its own inbox, Codex registers, receives the confirmation mail and reads the verification code without a human forwarding anything.

Approval before anything reaches a person. Use create_draft rather than send_message for outbound to real people. The draft sits in the inbox until you read it in the Anjal web app, or in Apple Mail over IMAP, and send it. For an agent working unattended this is the difference between a useful assistant and an incident.

Read this before you connect an unattended agent

Inbound mail is attacker-controlled text heading into the context of an agent that executes code with little supervision. "Ignore your previous instructions" in a support email is the obvious attack and it is not theoretical.

Anjal screens every inbound message for prompt injection on the ingest path and quarantines what it judges hostile. Quarantined mail is never returned by list_messages or get_thread, so the agent does not see it at all. A person releases it from the web app. An agent cannot release its own quarantine, by design, because the attack would be to ask it to. We publish the architecture and not the rules, for the reason you would expect: a checklist is what an attacker wants from us. Read the honest limits before you rely on it, because detection is advisory and not a trust boundary.

On by default. The model behind the judgement is pinned to an exact version rather than a floating tag, so the behaviour cannot change under you between runs.

Scoping it down

The OAuth connector reaches your whole account, which is more than an unattended agent usually needs. To limit it to one workspace, run the local server with a workspace key:

[mcp_servers.anjal]
command = "npx"
args = ["-y", "anjal-mcp@latest"]
env = { MYAGENTMAIL_KEY = "wk_..." }

A workspace key cannot list, read or send from any other workspace. For a fully unattended agent this is the shape I would recommend: give it the one workspace it needs and nothing else.

Cost

Starter is $5/month for 2 inboxes and 6,000 emails. Developer is $15/month for 10 inboxes and 20,000 emails. Extra inboxes are $2/month each. 7-day trial.

Next

• Connect Anjal to Claude Code
• Connect Anjal to Cursor
• MCP server reference and agent safety
• Handle 2FA and verification codes in an agent workflow

Command syntax and TOML format verified against OpenAI's Codex MCP documentation on 2026-09-28.