Codex · MCP
Codex does the work.
A person signs it off.
Get the lead's or the on-call engineer's approval on the steps of a long Codex run that need it, without them watching your terminal, and keep a record of who allowed each one. Today the approval Codex asks for is answered by whoever started it; connect Deliverd once and the question goes to the person who owns the decision, and the answer comes back to Codex.
No card required · Approvals on every plan · No token to paste
The situation
What happens when Codex needs a person today
The approval lives in a terminal nobody else can see
Codex pauses and asks the person who launched it. The person who should decide — the lead, the on-call engineer, the client — is somewhere else, and there is no way to put the question in front of them.
A long run has many consequential steps
Forty minutes in, the fifth prompt is answered like the first four. Each one deserved a different person, a different level of care, or a rule that said it was fine.
The trace says what ran, not who allowed it
When one of the calls turns out to matter, the question is who said it could and what they were looking at. A transcript was not built to answer that.
Setup
Connect Codex
Codex asks a named person before it acts, with no token to paste — and publishes what it builds straight from the CLI.
codex mcp add deliverd --url https://deliverd.dev/api/mcp
- 1
Add the server
codex mcp add deliverd --url https://deliverd.dev/api/mcp
- 2
Approve it in your browser
codex mcp login deliverd
Codex needs this second step — it does not begin the approval flow on its own.
- 3
On an older Codex
Streamable HTTP servers are only picked up when the rmcp client is on. If the server does not appear, upgrade Codex, or add [features] experimental_use_rmcp_client = true to ~/.codex/config.toml above the server entry.
No token is written anywhere. Deliverd implements the MCP authorization spec, so the client registers itself and you approve it in a browser — and removing someone from your organisation cuts their connection off at once, rather than whenever a token happens to expire.
Or paste this into Codex
It runs the installer, tells you what it connected, and proves the connection by asking you to approve something. One step is yours: approving the connection in your browser.
Set up Deliverd so you can ask me for approval and publish work for me. 1. Run: npx deliverd setup --url https://deliverd.dev It looks for Claude Code, Codex, Claude Desktop, Cursor and Muse Code on this machine and adds the Deliverd MCP server to each one it finds. There is no API key to paste. 2. Tell me exactly what it connected and what it says to do next. Some tools need a restart, Codex needs "codex mcp login deliverd" and Muse Code needs "muse mcp login deliverd" before the connection is live. 3. Once you can see the Deliverd tools, prove the connection by asking me for an approval with the request_approval tool. Title it "Hello from Deliverd", say in the description that it is a test of the connection, and leave the approvers out so it comes to me. 4. Give me the URL it returns, then poll get_approval until I have decided and tell me what I said. From then on, ask me the same way before anything consequential; when there is a report to share, publish it with publish_report. If npx is unavailable, install the CLI first with: npm install -g deliverd
Teach it when to ask, and how to build
Open-source skills Codex reads from disk. The approval skill teaches it when to stop and ask a person, and how to act on the answer; the ethics skill, when work could harm someone and that concern belongs in front of whoever decides; the artifact skill, how to build a page that holds up once published; the tasks skill, how to keep long work on its objective; the compliance skill, how to work under an organisation's AI governance and leave evidence an auditor can check.
npx skills add deliverd-dev/deliverd-skills --skill approval
npx skills add deliverd-dev/deliverd-skills --skill ethics
npx skills add deliverd-dev/deliverd-skills --skill artifact
npx skills add deliverd-dev/deliverd-skills --skill tasks
npx skills add deliverd-dev/deliverd-skills --skill compliance
What you get
Once it is connected
Everything below is one call from Codex, over the connection you just made — the ask first, and publishing last.
One call to ask a person
request_approval, request_review or request_information over the connection above. The agent says what it wants to do, why, and what it affects, and the question goes to a named person — not to whoever is at the keyboard.
Decided wherever they are
They approve, correct a figure the agent marked as correctable, reject with a reason or ask the agent a question — on a page built for a phone, from an email link, or from a Slack or Teams card. A colleague can cover while they are away.
The agent carries on
The decision comes back as something the agent can branch on: poll get_approval, wait on a callback URL, or let the SDK block. Approved, it does the action. Rejected, it stops and knows why.
A check before it acts
Before a payment, a deployment or a message to a customer, check_gate declares the action. With no rules a named person decides every one; with rules, the routine cases are settled and the rest go to a person.
A record of who allowed what
Who was asked, what they were shown, what they decided and when — kept as the work happens, and exported as an evidence pack in JSON, CSV or PDF with a digest so an altered copy can be told apart.
And when there is a report, a URL instead of a file
publish_report puts the HTML the agent writes on an address behind your organisation's sign-in, versioned, with comments anchored to the passage they are about. One capability among the rest, over the same connection.
request_approval over the connection above, answered on a page that works on a phone, with the decision back in Codex as soon as it is made. See how approvals work →Questions
Codex and Deliverd.
Which Codex versions work?
Any version with the rmcp client, which is what speaks Streamable HTTP. On an older build the server will not appear at all — upgrade Codex, or set experimental_use_rmcp_client = true under [features] in ~/.codex/config.toml.
Why the second command?
Codex does not start the approval flow on its own the way the Claude clients do. `codex mcp login deliverd` opens the browser; without it you get an authorization error that never resolves itself.
What can Codex do once it is connected?
Ask a named person for approval, a review or information it is missing, check a gate before a consequential action, and keep a task's objective and state across sessions — all over the same connection. It can also publish a report, update it in place, read reader comments and resolve them.
Can I use it from CI instead?
Yes. The CLI reads DELIVERD_URL and DELIVERD_TOKEN from the environment, so a pipeline can ask a person with deliverd ask --wait and fail the build unless it is approved, or publish with an agent identity scoped to one workspace.
Does JavaScript run in a published prototype?
Yes, from the report itself. Scripts and styles you inline run normally; the report cannot call out to other origins, which is what makes it safe to host untrusted generated code.
Let Codex act. Know who said it could.
One call to ask a person, answered where they are, and a record of who allowed what — from the tool you already have open.