Codex MCP Setup for Web Hosting: Deploy and Fix Failed Builds

A codex mcp entry is three lines of TOML, and it changes what you can hand to OpenAI’s Codex CLI. Instead of “write this feature”, you can say “ship this feature and verify it is live”, and Codex can check the result on Voroa itself. This guide covers the config entry, the sandbox and approval settings that decide whether a push even leaves your machine, how to phrase a ship-and-verify task, and why you should still read the diff first.

What Codex CLI is missing out of the box

Codex works inside your repository with the tools already on your machine. It is good at the edit, test, commit part. It has no idea whether your hosting accepted the result. Voroa’s MCP endpoint, which Voroa runs for you, answers exactly that question: did the deploy start, did it pass, and if not, what does the build log say.

The `config.toml` entry for Voroa

Install Codex if needed (npm install -g @openai/codex, or Homebrew, or the shell installer) and sign in with a ChatGPT plan or an API key. The Codex repository on GitHub lists every install route.

Next, create a Voroa token under Settings, API tokens in the dashboard. You will see its voroa_cat_ value only at creation. Export it in your shell profile as VOROA_TOKEN, then add to ~/.codex/config.toml:

toml

[mcp_servers.voroa]
url = "https://api.getvoroa.com/mcp"
bearer_token_env_var = "VOROA_TOKEN"

Codex sends that variable as an Authorization: Bearer header, so the secret stays in your environment and out of the file. The Codex MCP page lists the other supported fields. If Codex cannot name your real services when asked, our AI client connection checks cover the usual causes.

Sandbox and approvals: why the first push fails

Codex runs commands in a sandbox, workspace-write by default, and network access for commands starts switched off. git push needs the network. So does ssh. Until you allow it, both simply fail:

toml

[sandbox_workspace_write]
network_access = true

Pair that with approval_policy = "on-request", so Codex can stop and ask you before a step you care about. Stay away from --yolo (--dangerously-bypass-approvals-and-sandbox), which removes every protection in one flag. OpenAI’s approvals and security notes describe each option.

Writing a “ship this and verify” task

A good task names the outcome, not just the change:

Upgrade express to the latest minor version, run the tests, push to main,
then use the Voroa tools to confirm the new deploy is live. If the build
fails, read the build log, fix the cause and try again. Stop after three attempts.

Flow diagram in four boxes: push code, then read deploy status, then read build log, then fix and redeploy

Codex pushes, then looks up the fresh deploy with get_deploy_history and watches get_service_status. On a red build it pulls get_build_log, edits, and pushes again. A green build with a dead service sends it to get_runtime_logs. Because Voroa builds every push when auto-deploy is on, the push is the deploy; the token is only for reading the outcome. The same task runs without a chat window through codex exec, handy after a scheduled dependency bump. More task ideas are in Voroa’s coding agent guide.

Read the diff before Codex pushes

On Voroa, a push to the deploy branch is a release. So the moment worth your attention is just before it. With on-request approvals, ask Codex to show git diff and wait for your go-ahead before git push. Thirty seconds of reading beats a rollback. If something slips through anyway, a services:act token lets Codex roll back to a deploy you already had.

Where Voroa draws the line for any Codex token

services:read covers the loop above. services:act adds redeploy, restart and rollback; services:write adds env variables and domains. Creating or deleting a service, database or domain is never done by the token: on services:admin Codex can propose it, and you approve in the dashboard within the hour. Codex can learn which secrets exist but never their contents, and no Voroa tool hands out a database password. See the full Voroa MCP tool list.

Shelling into the service when logs run dry

Your service’s SSH Access page holds a key list and a ready-made login line of this shape, where the user name is the service’s own ID:

ssh <service-id>@ssh.getvoroa.com -p 2222

The sandbox network setting above also covers ssh, but opening the session yourself is simpler. Tell Codex what you find. Edits made in there vanish at the next release unless they sit on a persistent disk, so look, then fix in git. Setup and troubleshooting: SSH into a running service.