Codex VPS Hosting: Run OpenAI Codex CLI on a Server

Why run Codex on a server

OpenAI describes Codex CLI as a coding agent that runs on your own computer, where it inspects files, edits them and runs the tools already installed there. That is exactly why a VPS helps: put the agent next to the code and the toolchain, and your laptop becomes a thin terminal.

• Long refactors, test runs and migrations keep going while your laptop sleeps.
• Work from a phone or a borrowed machine over SSH; the checkout and session history stay on the server.
• A fixed environment with the exact language versions and services your project needs.
• Scripted runs: codex exec is built for pipelines and cron-style jobs.

Do not confuse this with Codex cloud. Codex cloud runs each task in an isolated workspace on OpenAI's own infrastructure, launched from ChatGPT on the web, the desktop app, mobile or the terminal. A VPS is the opposite arrangement: you own the machine, the files and the network rules. Pick cloud if you want OpenAI to host the environment; pick a server if you want it on your side. For a local install first, see our Codex CLI install guide.

What the server needs

The install docs in the openai/codex repository list the supported systems as macOS 12+, Ubuntu 20.04+ or Debian 10+, and Windows 11 through WSL2. They give a 4 GB RAM minimum and recommend 8 GB, with Git 2.23+ optional. Unlike a thin client, Codex therefore has a stated floor: a 2 vCPU / 4 GB VPS meets the minimum, and 8 GB is the safer pick if your own builds and tests run on the same box. The model itself runs at OpenAI, so there is no GPU requirement.

Step 1: create a non-root user and install Codex

Codex runs shell commands as the Linux user that starts it, so give it its own unprivileged account on a machine that holds nothing else you care about.

adduser --disabled-password --gecos "" cx
sudo -iu cx
curl -fsSL https://chatgpt.com/codex/install.sh | sh
exec bash -l          # reload so the new PATH entry applies
codex --version

The standalone installer is the route the README and CLI docs lead with. It downloads the compiled binary, so it needs no Node.js. The README also lists npm install -g @openai/codex and brew install --cask codex, and GitHub Releases carry per-platform binaries for Linux x86_64 and arm64. Rerunning the installer is also the documented way to update.

Step 2: sign in on a machine with no browser

The default "Sign in with ChatGPT" flow opens a browser, which a server does not have. The authentication docs give you four ways around that, with device code as the preferred one:

1. Device code (beta): enable device code login in your ChatGPT security settings, run codex login --device-auth on the server, open the link on any device, sign in and enter the one-time code.
2. API key: printenv OPENAI_API_KEY | codex login --with-api-key reads the key from stdin so it never lands in your shell history.
3. Copy credentials: sign in on your laptop, then copy the cache across:

   ssh user@remote 'mkdir -p ~/.codex && cat > ~/.codex/auth.json' < ~/.codex/auth.json

4. Port forwarding: the normal browser login uses a localhost callback, default port 1455. ssh -L 1455:localhost:1455 user@remote forwards it so you can finish the login in your laptop's browser.

Credentials are cached in ~/.codex/auth.json by default or in the OS credential store, controlled by cli_auth_credentials_store in your config: file, keyring, auto or ephemeral. On a server without a desktop keyring, file is the practical choice, and it means anyone with a shell as that user can read the token. That is one more reason to keep this box single-purpose. Whichever login you use, model usage is billed to that ChatGPT plan or API account; the README lists Plus, Pro, Business, Edu and Enterprise plans for ChatGPT sign-in. Our guides on the Codex OAuth route and Hermes Agent with Codex cover the subscription side from the chat-agent angle.

Step 3: keep sessions alive

An interactive codex session belongs to your terminal, so run it inside tmux and reattach after a dropped connection:

tmux new -s codex
cd ~/project && codex
# detach with Ctrl-b d, later:
tmux attach -t codex

For unattended jobs use codex exec. It streams progress to stderr and prints only the final message to stdout, so it pipes cleanly. The documented flags worth knowing on a server are --json for JSON Lines output, -o <path> to write the final message to a file, --output-schema for structured results, --skip-git-repo-check to run outside a Git repository, and --ephemeral to avoid persisting session files.

CODEX_API_KEY=<key> codex exec --sandbox workspace-write "fix the failing tests"
codex exec resume --last "now update the changelog"

codex exec defaults to a read-only sandbox, so without --sandbox workspace-write it can look at the repository but not change it.

The two errors that bring people here

"Codex CLI is not installed on this remote machine"

This is a message from Codex's remote connections feature, not from the terminal CLI: the desktop app can run work on another machine over SSH. We could not find that exact string in the open-source CLI repository, so the cause below comes from OpenAI's remote connections page. It says the app starts the remote Codex app server through SSH using the remote user's login shell, and that you must install and authenticate Codex on the host and "make sure the codex command is available on the remote host's PATH in that shell." The app also reads concrete host aliases from ~/.ssh/config, so confirm that plain ssh alias works first.

ssh my-vps 'bash -lc "command -v codex && codex --version"'

If that prints nothing, Codex is missing for that user or your login shell does not put its directory on PATH. Install it as the same user you connect as (Step 1), then check again. Our own check above is a quick way to test it; the requirement itself is the documented one.

"This CLI has no complete local package" and --no-daemon

Both strings are in the openai/codex source. Recent Codex versions can attach to a shared background server (the daemon, in the codex-app-server-daemon crate) instead of starting an embedded one. When the daemon has to install its own managed copy under CODEX_HOME/packages/app-server-daemon and the CLI you ran is not a complete installed package, it fails with "this CLI has no complete local package; install a packaged Codex CLI or use the standalone installer". The crate's README adds that "a bare executable cannot supply a new installation", which is what you get from copying a lone binary onto a server or running a local build. The TUI then appends its own hint: to work without the background server, rerun the same command with --no-daemon, including resume or fork and their arguments.

You have two fixes:

• Install properly: run curl -fsSL https://chatgpt.com/codex/install.sh | sh and launch the installed codex.
• Skip the daemon: repeat the same command with --no-daemon, for example codex --no-daemon, so Codex runs its own embedded server.

The daemon README marks the daemon as experimental and says its lifecycle contract may change. It describes it as the backend for remote clients such as the desktop and mobile apps, for Codex instances launched over SSH, and documents codex app-server daemon bootstrap --remote-control for fresh machines. Running a plain terminal session over SSH, as in this guide, does not require you to use any of it.

Sandbox and approvals: read this before leaving it running

Codex has its own safety layer, and it is worth understanding because nobody is watching a prompt on a headless box. The docs define three sandbox modes: read-only, workspace-write (the interactive default, which allows edits inside the working directory) and danger-full-access (no sandbox). Approvals are a separate setting, so full access does not by itself stop Codex asking; --yolo is the flag that drops both. With approval_policy = "on-request", Codex asks before editing outside the workspace or using the network. Network access is off by default and is enabled with network_access = true under [sandbox_workspace_write]. In workspace-write, .git, .agents and .codex stay read-only even though the rest of the workspace is writable; danger-full-access removes that protection too.

On Linux the filesystem sandbox is bubblewrap. The linux-sandbox README says Codex uses a bwrap found on PATH and otherwise falls back to a bundled copy, and that it shows a startup warning when bubblewrap cannot create user namespaces. Treat that warning on a VPS or inside a container as real: it means the sandbox you are counting on is not fully available. Settings live in ~/.codex/config.toml (user) and .codex/config.toml (project), with CLI flags overriding both.

# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
cli_auth_credentials_store = "file"

A sandbox is not a substitute for isolation. The agent still runs as your Linux user, so keep the VPS free of other secrets, and keep --yolo for a disposable box.

Reaching it remotely, safely

For the terminal CLI you only need SSH: key-only login, no password auth, no extra ports. Codex is not a service you expose. OpenAI's remote connections docs are direct on the other point: "Don't expose app-server transports directly on a shared or public network", and if you must reach a machine outside your network, use a VPN or mesh tool such as Tailscale rather than opening a port. The same rule applies if you try the desktop app's SSH hosts or the daemon: leave everything bound to localhost, reach it over SSH or your tailnet, and never open a Codex port on the VPS firewall.

Updating

Rerun the installer to update the CLI. If you use the experimental daemon, its README says a managed daemon checks for updates five minutes after start and then hourly by default; change that in CODEX_HOME/app-server-daemon/settings.json, or run codex app-server daemon update by hand. A running daemon restarts on update, which can interrupt active work.

VPS or managed: what it costs

Codex usage is billed to your own ChatGPT plan or API account in every row. See the Codex CLI comparison for how it stacks up against other agents.

The managed option: Coding Harness

OpenClaw Launch's Coding Harness is a hosted Linux workspace you open in the browser, with eight coding CLIs pre-installed: Claude Code, Codex, OpenCode, Aider, OpenClaude, Zero, Pi and DeepSeek Harness. Pick one from the workspace card; all share one persisted /workspace directory, with Reset and Wipe available. You sign in to Codex the native way, in the terminal: ChatGPT subscription OAuth or an API key, for example codex login --device-auth. The workspace deliberately does not inject your saved provider API keys under the variable names a CLI reads, because an ambient API key would silently override a subscription login and bill pay-per-token instead.

Telegram works too: click Telegram on the workspace card, paste a new bot token from @BotFather and open the one-time pairing link. Each message to that bot then runs Codex, Claude Code or OpenCode inside the workspace, follow-ups continue the same conversation, and the result comes back in chat; only the paired Telegram account can use it. A workspace uses one of your plan's instance slots at normal plan pricing and is sized by plan. There is a 30-minute free trial with no credit card, sized as Lite. See the tools directory and Codex with OpenClaw.

OpenClaw Launch also hosts chat agents (OpenClaw and Hermes Agent) on Telegram, Discord, WhatsApp and more. That is a different product from a coding workspace; see Hermes hosting and hosting.

Frequently Asked Questions

Related Guides

• Coding Harness hosting — the managed workspace
• Codex CLI install guide
• OpenClaw with Codex OAuth
• Hermes Agent with Codex
• Claude Code VPS hosting
• DeepSeek Harness VPS hosting
• Pi coding agent in a hosted workspace
• Codex CLI comparison