project note / chatgpt site + mcp

Codex for
Everything.

A ChatGPT-hosted project on its own domain, with Sites-managed Sign in with ChatGPT for the browser and a separate OAuth 2.1 boundary for MCP clients.

What this is.

Codex for Everything is an independent project around Codex workflows. It is not affiliated with, endorsed by, or sponsored by OpenAI, ChatGPT, or the Codex product team. The production web surface is a ChatGPT-hosted Sites project published at codex-for-everything.com.

The useful part is the boundary design. Browser visitors can use Sites-managed Sign in with ChatGPT. MCP clients do not inherit that browser session; they discover and complete their own OAuth flow before reaching a small read-only tool catalog.

The linked project repository documents the hosted contract and contains the local Node service and static preview. Production route handlers and hosting configuration are kept in a separate deployment repository.

Deployment shape.

01 / Sites project

Keep the project identity stable.

The deployment repo retains the Sites project ID in .openai/hosting.json. That connects each version to the existing hosted project and its attached custom domain.

02 / App build

Build the site with vinext.

The production app uses Next.js through vinext. Local checks run with npm install, npm run build, npm test, and the MCP protocol suite.

03 / Domain

Attach the domain once.

codex-for-everything.com is the primary address. Future deployments target the same Sites project, so the domain does not move with every release.

04 / Sign-in routes

Do not rebuild platform auth.

Sites dispatch owns /signin-with-chatgpt, sign-out, callback, cookies, and identity-header injection. Protected pages call small server helpers instead of defining those routes.

05 / MCP storage

Add only the durable state OAuth needs.

The hosting file declares a D1 binding. Migrations store consent, hashed one-time codes, hashed access tokens, revocation state, and rate-limit buckets. R2 stays disabled.

06 / Deploy + verify

Test the real domain after release.

Set the MCP HMAC secret in Sites, deploy, then verify OAuth metadata and /api/mcp on the custom domain. Local tests cannot prove the hosted callback flow.

Implemented layers.

01 / Domain

The hosted site has its own address.

The production Sites project is available at codex-for-everything.com. The MCP endpoint lives on the same domain at /api/mcp.

02 / Browser identity

Sites owns the sign-in route.

The hosting platform handles sign-in, sign-out, and callback routes, then forwards authenticated-user headers to server-rendered routes.

03 / MCP discovery

Clients get a real OAuth contract.

Protected-resource and authorization-server metadata advertise registration, authorization, token, revocation, and MCP endpoints.

04 / OAuth boundary

Browser identity is not a bearer token.

MCP uses dynamic client registration, PKCE S256, exact redirect URI checks, scoped expiring tokens, single-use codes, and resource binding.

05 / Read-only tools

The connector starts small.

get_connector_status, search_capabilities, and fetch_capability expose the catalog without running Codex or changing repositories.

06 / Source split

Shared contract, separate deployment.

The linked repo explains the endpoint and auth model. Production route handlers and hosting configuration remain separate from the local Node tooling and static preview.

Why the split matters.

A / Three credentials

One person, three security contexts.

Local Codex sign-in, hosted browser sign-in, and the hosted MCP bearer token are separate. Treating them as interchangeable would erase the security boundary.

B / Narrow first release

Discovery before execution.

The hosted MCP connector can report status and describe capabilities, but it cannot run Codex, submit proposals, or perform write actions.

C / Honest documentation

The repo says what it can prove.

It documents the deployed URL, endpoint map, OAuth controls, and tool list without pretending the static preview is the production Sites code.

Request paths.

browser
custom domain

A visitor opens the project URL.

The request lands on the ChatGPT-hosted site at codex-for-everything.com. The custom domain is the public product address.

browser
chatgpt sign-in

Sites handles browser authentication.

The platform owns the sign-in and callback lifecycle. Authenticated-user headers are passed to the site after the browser flow succeeds.

mcp
oauth 2.1

An MCP client follows a different path.

The client discovers metadata, registers dynamically, uses PKCE, receives a scoped token, and presents that token to /api/mcp.

2026-08-15
public note

The architecture was written down.

The public project note focuses on the part worth reusing: a branded domain, managed browser identity, and an MCP surface with its own explicit authorization contract.

Why write this down.

“Add Sign in with ChatGPT” and “add MCP” sound like one feature. They are two trust boundaries. This build keeps them separate, gives each client the right credential flow, and starts the connector with tools that cannot mutate anything.

View the repo Back to projects