Codex · MCP

Codex builds it.
Deliverd gives it an address.

A prototype nobody can open is a prototype nobody can react to. Connect Codex once and it can publish what it builds to a URL, with the right people already able to see it.

No card required · Unlimited viewers · Secure by default

The situation

What happens to Codex's output today

Reviewing means running it

“Pull the branch and npm run dev” is a fine ask for an engineer and an impossible one for the person who actually needed to see the thing.

Screenshots lose the point

The interactive part is the point. A picture of a dashboard cannot be filtered, sorted or clicked, which is most of what you wanted feedback on.

Deploying a throwaway is too much work

Standing up hosting, a domain and an auth layer for something that might be discarded on Friday is why it stays on localhost instead.

Setup

Connect Codex

Publish what Codex builds straight from the CLI, with no file to move and no token to paste.

  1. 1.

    Add the server

    codex mcp add deliverd --url https://deliverd.dev/api/mcp
  2. 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. 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.

What you get

Once it is connected

Everything below is what happens to a report after Codex publishes it.

A URL instead of a file

The report lands on an address you can send. It stays put, so a link you shared last month still opens the report — not a stale copy of it.

Behind your own sign-in

Readers authenticate with the identity your organisation already uses, including SAML single sign-on. Nobody gets a password to remember or a file to lose.

You choose who, in plain English

“Finance team”, “Sarah Jones”, “everyone”. Ambiguous phrases come back as a list to pick from rather than a guess, so a board pack cannot land in the wrong inbox.

Every version kept

Publishing again updates the same URL and keeps what was there before. You can see what changed, and roll back if the new one is wrong.

Comments on the passage, not the page

A reader selects a sentence and comments on it. Your agent can read those threads, fix what they point at, and mark them resolved.

A record of who opened it

Views, versions, access changes and share links are all written to an audit trail you can export.

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.

Can I use it from CI instead?

Yes. The CLI reads DELIVERD_URL and DELIVERD_TOKEN from the environment, so a pipeline can 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.

Stop sending Codex’s output around as files.

Publish it to an address instead, and let the people who need it open it with the sign-in they already have.