Deploy with Codex

Paste one prompt into Codex and it deploys your app from its saved managed or GitHub source through the 114 local MCP tools: hosting, Postgres, a domain and mail from one balance. Free gives 200 credits a month; Paid is $10 for 1,000. A non-expiring token and a stop budget let the agent run without you watching.

Paste this prompt

Open Codex in the repository you want to deploy and paste this:

Read https://ohmyho.st/llms.txt and https://ohmyho.st/skills/ohmyhost-get-started/SKILL.md. Connect this agent to ohmyho.st and develop and deploy this application using only the capabilities it needs. Read the existing project source first and follow the get-started Skill to reuse GitHub or managed versions for this workspace. After signing in, use the user and organization that whoami reports; never guess an account, organization or project ID. Follow the deployment Skill, keep my existing project decisions and verify the app.

Codex reads llms.txt and the get-started Skill, then follows the deployment Skill. It stops only for the things you alone can do: the browser sign-in, GitHub authorization when that source is selected, and for a new project the region and whether Dev and Prod share data. Everything else is a tool call it plans and you confirm.

How to deploy with Codex

1. Register the local MCP server: codex mcp add ohmyho -- ohmyhost-mcp. The Skill's harness reference adds --env OHMYHOST_ENVIRONMENT=production before the --. Codex writes the entry to ~/.codex/config.toml, which the Codex CLI and the IDE extension share (learn.chatgpt.com, read 2026-09-20). If ohmyhost --version fails, install the CLI and MCP packages first from the CLI and MCP guide.
2. Paste the prompt above. Codex runs ohmyhost whoami --json and lists the ohmyho tools before it touches anything; a saved configuration alone is not a connection.
3. Sign in once. Codex runs ohmyhost login --json and prints a link plus a confirmation code such as ABCD-EFGH. Open the link, check that the page shows the same code, then sign in or sign up. No password, email code or token value ever goes into the chat.
4. Review the plan. Codex reuses the current project/source or calls project_create for a new one. It saves a managed version or uses source_link for the selected GitHub repository, then calls deployment_plan for that exact commit. The plan reserves 14 build minutes, about 16.87 credits, settles the measured seconds afterwards, and lists required secret names and blockers. Secrets go in through the stdin-only command returned by secret_set_command, never through the chat.
5. Verify. After deployment_create, Codex polls operation_get, reads the URL from project_status, opens Dev through the owner's reusable share link from project_dev_share_link_get (or the clean URL, for public Dev) and tests login plus a real read and write before it reports a URL as working.

These examples use the local stdio client. When the client exposes authenticated remote MCP, follow the get-started Skill for OAuth and explicit project/preview/publishing grants; discover its actual tools instead of assuming this local catalog. Private application values then use secret_input_request and its same-account portal link rather than local stdin. A new app developed entirely in chat starts with managed versions. This describes the supported transport contract, not a claim that a particular native chat UI has completed acceptance.

What Codex does next

The 114 local tools cover the whole lifecycle, and the expensive or destructive ones come in pairs: deployment_plan → deployment_create, promotion_plan → promotion_execute, rollback_plan → rollback_execute, delete_plan → delete_execute. The plan is data you can read; the execute call carries the plan and one saved idempotency key, so a retry after an uncertain response cannot deploy twice.

• Resuming: project_context_get returns status, DNS and mail next actions and shared notes, so a new session does not re-read the repository.
• Auth: deployment_plan preserves your existing application auth, Better Auth or your own WorkOS AuthKit tenant. The platform login is separate and never becomes your app's users.
• Diagnosis: deployment_logs carries the sanitized tail of a failed build; operation_logs is a bounded ten-second snapshot, not a wait.
• Data: database_query reads at most 100 rows; database_write needs confirmation and an idempotency key; database_access_create issues a time-bound psql credential shown exactly once.
• Mail: sending needs Paid and a verified mail domain. mail_setup starts it and mail_status returns the DNS records and reports sending and receiving readiness until they verify.
• Leaving: project_export_create produces a password-encrypted ZIP with a portable SQL dump, one accepted request per project per rolling 24 hours, signed link valid 24 hours. Free, even at zero credits.

Running without a human present

This is the part an agent builder came for. Four tools, in this order.

1. token_create, after one interactive login. It writes a non-expiring API token to the private env file you name, mode 600, and returns only metadata and the path; an existing token is never overwritten. Load that file into the process that runs Codex and OHMYHOST_TOKEN overrides the saved login. A token cannot create, list or select workspaces, or create, list or revoke tokens: do those once, interactively. Details: login and tokens.
2. project_budget_set as the ceiling. A budget is a UTC-month limit in microcredits (1,000,000 microcredits is one credit) with two modes. continue keeps drawing from the organization's balance past the threshold; stop rejects new billable work with project_budget_exceeded and pauses the project's traffic with HTTP 402. Set stop at the Free allowance, 200 credits, and a loop that redeploys every failed build ends on its own instead of draining your top-ups. Changing a budget never resets usage or adds credits (budgets).
3. organization_credits_get before a run. It returns the shared balance, the grace window if one has started and the published rate cards, and it works at zero credits. An agent that reads it first declines a deployment it cannot fund instead of failing halfway. organization_usage_get adds the posted usage by project, environment and meter for the month.
4. feedback_submit when something looks wrong. It takes a redacted expected-versus-actual description and a minimal reproduction, returns a receipt ID and works at zero credits. No credentials, no raw logs.

The trade-off: an unattended agent cannot buy credits. billing_checkout_create is Owner-only and the Skills start it only on request, and automatic recharge stays off unless the Owner turns it on. A run that empties the balance starts a seven-day grace period in which funded services keep running; after that only unfunded services suspend, and data, diagnosis and export stay available.

What an agent reads

Four public files, no login required:

• llms.txt — the index an agent reads first. It links the Skills, the docs and the tool catalog, and it never contains account data.
• /.well-known/agent-skills/index.json — the current Skills with descriptions, each served at /skills/<name>/SKILL.md, for example ohmyhost-usage-and-budgets.
• /mcp-tools.json — the 114 tools with their descriptions, the same catalog the local server exposes. It is a catalog, not a remote endpoint; ohmyhost-mcp runs on your machine.
• The OpenAPI 3.1 contract — the REST /v1 API behind the CLI, the MCP server and the SDK. An agent that prefers plain HTTP calls it with the same token.

Dev and Prod

Every project gets two environments on <three-words>.check.omh.st. Dev is protected by default: anonymous requests get a 404, and Codex opens it through the reusable share link from project_dev_share_link_get, which has no automatic expiry until the owner rotates or revokes it. Public Dev is an explicit choice when the project is created. Prod is reached in two ways: promotion_plan → promotion_execute moves the verified Dev artifact without a rebuild, and with isolated data deployment_plan with environment: "prod" builds a commit straight into Prod. A project whose Dev and Prod share a database always deploys to Dev and promotes.

At project_create, data mode is optional and defaults to shared: one database and file area for both environments. Isolated data uses separate areas, with databases metered separately and promotion applying migrations without copying Dev rows. An Owner can later use project_data_plan → project_data_change to keep existing data with Prod or Dev, return to shared, or reset isolated Dev. No records or files are copied and ordinary usage prices apply. Sharing keeps Prod and permanently removes the separate Dev data, files and deployment; resetting Dev removes its area and deployment. Review and confirm that plan before executing. The region is chosen once, US by default or EU, at identical prices; it cannot change later. A customer-owned domain on Prod needs Paid and uses credits; on a project that shows the opt-in “Powered by ohmyho.st” flag it also works on Free and uses no domain credits, through domain_paid_plan → domain_paid_apply after an active Prod deployment.

What it costs

Free: 200 credits per UTC month. Paid: $10 a month for 1,000 credits per period. Monthly credits expire at period end without rollover. Paid-only top-ups carry over until downgrade to Free and come at 100 credits per dollar up to $100 and 125 per dollar above. Every project draws from the organization's one balance; there is no per-project base fee.

An agent loop spends on builds, requests, database activity and retained resources. One active database hour at 512 MiB RAM costs 20.00 credits; the 256 MiB size available on Free costs 10.00 credits. Databases sleep after five idle minutes, with no active-RAM charge while asleep. Allocated disk and seven-day backups are included. Customer files and retained Worker scripts keep their separate rates. Each deployed script uses about 6.57 credits a month. Workers bandwidth is not charged.

About $1.40 of credit value at the standard rate.

Compare that total with 200 Free or 1,000 Paid credits a month, and set the stop budget from it. The full rate card is at /pricing/breakdown and docs.ohmyho.st/pricing.

What we have tested, and what we have not

On October 27, 2026 we started the locally installed ohmyhost-mcp (version 0.1.36) over stdio from a script, sent initialize and tools/list, and read the answer. It listed identity_get, source_inspect, deployment_plan, deployment_create, deployment_logs, promotion_plan, promotion_execute and secret_set_command. The captured result is in our public repository.

That is a protocol check of the shared tool server, not a Codex session. We have not published a transcript of Codex deploying an app, tested an unattended run, or checked the Codex IDE extension. The same check applies to Claude Code and Cursor.

FAQ

Is there a recorded Codex deployment I can look at?

Not yet. When we record a real Codex run with its commands and resulting address, it will be added here with its date.

Does Codex need a human for every deployment?

No, only for the first one. The sign-in, the workspace selection and token_create are interactive once. After that a process with OHMYHOST_TOKEN loaded from the mode-600 env file can plan, deploy, promote, roll back and read usage on its own. Set a stop budget with project_budget_set first, so the ceiling is the platform's rule, not the model's judgment.

Where does the API token live?

In a private env file you choose, written by token_create with mode 600. The tool returns metadata and the file path, never the value, and it never overwrites an existing token. The Skills keep credentials out of chat, source and command arguments. Revoke a token with token_revoke from an interactive session when it is no longer needed.

What stops an agent from spending everything?

A project budget. project_budget_set in stop mode rejects new billable work with project_budget_exceeded once the UTC-month threshold is reached and pauses the project's traffic. Automatic recharge stays off unless the Owner turns it on, so nothing buys more credits on its own; a zero balance starts a seven-day grace period during which funded services keep running.

Can Codex deploy something other than a GitHub repository?

Yes. The current project binding can use managed versions or a GitHub repository you select. For an unbound checkout without GitHub, choose once whether to keep versions with ohmyho.st or set up GitHub; an explicit choice already counts. The app must still fit a supported Astro, Next.js, Vite/React or TanStack Start runtime; there are no containers. ohmyhost init --dry-run --json reports blockers before any credit is reserved, and the portable-app Skill covers the source changes a blocker usually needs.

Does this work with the Codex IDE extension too?

Yes. The MCP entry lives in ~/.codex/config.toml, which the Codex CLI and the IDE extension share for the same host (learn.chatgpt.com, read 2026-09-20). ohmyhost-mcp runs locally with Node.js, so a second computer needs its own installation and its own login or token file.

Deploy with Claude Code · What is open · Cost breakdown · Six things that break when a vibe-coded app meets production