How to Deploy a Website with OpenAI Codex (No GitHub)

Build the site into dist/, add Wibe to the Codex CLI, authorize the remote MCP connection, and ask Codex to publish the finished files. You get a stable live URL without pushing the repo to GitHub or uploading a ZIP to another dashboard.

1. Step 1BuildCreate dist/index.html
2. Step 2ConnectLog in to the Wibe MCP
3. Step 3DeployPublish and test the URL

What Codex builds — and what hosting still has to do

OpenAI Codex is an AI coding agent. It can inspect a codebase, edit files, run commands, test a build, and work with a GitHub repository. OpenAI provides Codex in ChatGPT, the desktop app, an IDE extension, and the terminal. Those surfaces help with software development; they do not make every generated website or app compatible with the same hosting workflow.

A landing page, portfolio, documentation site, or client-side prototype is usually a good static use case. A web app that owns authentication, a database, server API routes, background jobs, or private API keys needs application hosting. Read the static site versus application test before deploying if the boundary is unclear.

Ask Codex to classify the current workspace before changing it:

Inspect this project without changing it. Decide whether it can run entirely as a static website after a production build. Check the framework, package scripts, server routes, authentication, database code, background jobs, private environment variables, and local binary assets. End with either "Ready for the Wibe static publish workflow" or a specific list of blockers.

Step 1: Build the Codex website into dist/

Wibe hosts production output, not a development server. The final directory needs dist/index.html as its entry point, with every referenced CSS and JavaScript file below dist/. Relative asset paths must still work from a hosted URL.

You do not need to guess the build command. Ask Codex to inspect the existing framework and scripts, preserve the current architecture, and run the real production build:

Prepare this codebase for a static Wibe deployment. Inspect the package scripts and framework configuration before editing. Run the correct production build and make the final browser output available under dist/ with dist/index.html present. Check internal links and asset paths from a hosted URL. Do not publish yet. Report the command you ran, the directory contents, and every blocker.

A working preview on localhost is not enough. The production output must exist and must not depend on a local process after the build finishes.

Step 2: Connect Wibe to the Codex CLI

Add Wibe as a Streamable HTTP MCP server. This gives the AI agent a narrow set of project, publish, version, and rollback tools:

codex mcp add wibe --url https://birta.dev/mcp

Then start the browser authentication flow:

codex mcp login wibe

Sign in with the one-time code sent to your email and allow access. Codex stores its OAuth authentication separately; there is no API key to paste into the repository. Check the integration with codex mcp list, or open Codex and run /mcp. The wibe server should appear.

If the command in your installed version does not accept the URL, configure the same server in ~/.codex/config.toml:

[mcp_servers.wibe]
url = "https://birta.dev/mcp"

The official OpenAI Codex MCP documentation covers remote servers, OAuth, config.toml, and the shared configuration used by the CLI, desktop app, and IDE extension. Wibe's Codex connection guide remains the short command reference.

Step 3: Deploy the Codex website to a live URL

Create a Wibe project in the dashboard if you do not already have one. Return to the same Codex workspace and use one explicit prompt. The agent should verify the output again, list available projects, and stop if the destination is ambiguous.

Use the connected Wibe tools to list my projects. Ask me to choose if more than one project could be the destination. Verify that dist/index.html exists and that every file you send is text. Publish all text files under dist/ to the selected project with the description "Initial Codex website publish". Keep nested paths intact. Return the live URL, version number, preview URL, and every warning exactly as Wibe reports them.

Wibe validates the package before changing the public site. A missing entry point or invalid payload is rejected while the current version stays live. A successful deploy returns the URL, preview, and recorded version.

Test the live URL, not only the local preview

AI-generated code can build successfully and still fail in a real browser. Open the deployed site in a private window so your local session and files cannot hide a problem.

1. Hard-refresh the home page on desktop and mobile.
2. Open every route and click navigation, buttons, and forms.
3. Check CSS, JavaScript, images, and fonts for 404 responses.
4. Inspect the browser console and network panel for errors.
5. Search the built files for secrets and private API keys.
6. Confirm that the live URL is the intended Wibe project.

If a local binary asset is missing, give it a public source or use another supported upload path. Repeating a text-only deployment will not transfer the binary file.

Wibe, Sites in Codex, or a full-stack platform?

Deployment use cases look similar in search results but need different infrastructure. Use this Wibe workflow when Codex already holds a finished static directory and you want a direct, versioned path to a shareable site. It avoids a repository connection, build-settings dashboard, and ZIP handoff.

If your OpenAI account or business workspace already provides Sites in Codex or a Vercel or Netlify plugin, that may be the shortest route to a working preview. Use application hosting when the project is a Node.js service or needs auth, a database, server-side APIs, persistent data, or secret environment variables. Do not force a full-stack web app into static hosting to simplify the deployment screen.

Iterate in Codex, then update or roll back

Keep working in the same codebase or worktree. After each visible change, review the diff, rebuild dist/, and deploy to the same project with a useful description. That turns each iteration into an understandable version instead of an anonymous overwrite.

Review the current changes, rebuild the static site, and verify dist/index.html. Check the built output for unexpected files and private values. Publish dist/ to the same Wibe project with the description "Update: [summarize the visible change]". Return the live URL, new version number, preview URL, and warnings. Then list the latest versions and identify which one is live.

If the new version is wrong, ask Codex to list the available versions first. Choose a known-good version and roll back. The later version stays in history, and the local repo is not changed.

List the versions of my Wibe project and mark the live one. Do not change anything until you show me the choices. After I select a version, roll back to it and return the restored version number and live URL.

Common Codex deployment problems

Wibe is missing from /mcp

Run codex mcp list. Add the server again only if it is absent. If it exists but authentication failed, run codex mcp login wibe and complete the browser flow.

The deploy has no index page

The payload does not contain dist/index.html. Inspect the framework output directory, rebuild from the project root, and place the finished static files under dist/.

The build expects a server

A route, API, database, or runtime environment variable is still required after the build. Choose application hosting; removing the error message does not make the architecture static.

Images or fonts are missing

Check URL paths and filename case first. If the files are local PNG, JPEG, WebP, PDF, WOFF, or WOFF2 binaries, they cannot travel through the current text-only MCP publish tool.

Codex picked the wrong project

Stop before publishing. Ask Codex to list projects with their names and addresses, then name the exact destination in the prompt. Never infer the target from a similar project name.

Frequently asked questions