How to Run Codex CLI on a Cloud VM

Published August 26, 2026 · by the AQ team

Running Codex CLI on a cloud VM takes about fifteen minutes: provision a small Linux server (Ubuntu 20.04 or newer with at least 4 GB of RAM), install the CLI with OpenAI's standalone installer, sign in once using device code login or an SSH port forward, and run every session inside tmux so it survives disconnects. The payoff is an agent that keeps working after your laptop lid closes and that you can reattach to from any device. Every Codex detail here is checked against OpenAI's own documentation and repository as of August 2026. This is the Codex twin of our Claude Code cloud VM guide; the two setups differ mainly in how sign-in works on a headless box.

Why put Codex on a server at all

On a laptop, a Codex CLI session dies with your terminal: close the lid mid-refactor and the process is gone. Codex softens this more than most CLIs because sessions are saved to disk as you go, and codex resume reopens the conversation with its context intact. But resume is recovery, not persistence: nothing executed while the laptop slept. On a VM the process runs on hardware that never sleeps, you check on it from any machine by reattaching, an agent running with relaxed approval settings is confined to a disposable box instead of the machine holding your password manager, and your credentials and repository clones get a stable home independent of any laptop.

Step 1: Provision the VM

OpenAI's stated requirements are modest: Ubuntu 20.04+ or Debian 10+ on the Linux side, with 4 GB of RAM minimum and 8 GB recommended. Any current Ubuntu LTS image works, and Codex ships static Linux binaries for both x86_64 and ARM64, so cheaper ARM instances are fine. Size for what runs next to the agent: 2 vCPUs and 4 GB handles the CLI plus a light toolchain, while heavy npm or cargo builds and a running dev server make 8 GB the comfortable floor. On a 4 GB machine, add swap so a hungry build gets slow instead of killed:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Any provider works. As of August 2026, a 2 vCPU, 4 GB basic droplet at DigitalOcean runs about $24 per month, Hetzner's CX22 shared vCPU plan with the same specs is under 4 euros per month even after its June 2026 repricing, and AWS Lightsail bundles start at $3.50 per month (IPv6-only; $5 with a public IPv4 address). Prices move; check the provider's page before committing.

Step 2: Ten minutes of hardening

An always-on box that will hold your GitHub and OpenAI credentials deserves basic hygiene before any agent touches it:

# As root, once
adduser dev
usermod -aG sudo dev

# Firewall: SSH only
ufw allow OpenSSH
ufw enable

# Keys only: in /etc/ssh/sshd_config set
#   PasswordAuthentication no
#   PermitRootLogin no
# then restart sshd

# Security patches apply themselves
apt install -y unattended-upgrades

Two optional upgrades: a mesh VPN such as Tailscale takes SSH off the public internet entirely, and mosh keeps your interactive connection responsive on flaky networks, though with tmux in the loop a dropped connection costs you nothing anyway.

Step 3: Install Codex CLI

Install the basics, then Codex itself. On a server the standalone installer is the cleanest route because it needs no Node.js:

sudo apt update && sudo apt install -y git tmux
curl -fsSL https://chatgpt.com/codex/install.sh | sh

If the box already runs Node, npm works too (npm install -g @openai/codex), and OpenAI publishes prebuilt Linux binaries on the GitHub releases page if you prefer to place the binary yourself. The CLI is open source under Apache 2.0. Confirm with codex --version.

Step 4: Sign in on a headless box

Codex is included with ChatGPT Plus, Pro, Business, Edu, and Enterprise plans, or you can authenticate with an OpenAI API key and pay per token. The catch on a server: the default sign-in flow opens a browser and completes against a local callback server on port 1455 of the machine running Codex, which a headless VM cannot do by itself. As of August 2026 there are three ways through, in order of preference:

Device code login. Run this on the VM:

codex login --device-auth

The CLI prints a URL and a one-time code; open the URL in the browser on your laptop or phone, enter the code, and the VM picks up the completed login on its own. No tunnel, no copied files. The prerequisite: device code login must be enabled in your ChatGPT security settings first (on workspace accounts an admin has to allow it), so flip that switch before you SSH in.

SSH port forwarding. If device auth is not enabled for your account, forward the callback port when you connect, then run the normal login inside that session:

ssh -L 1455:localhost:1455 dev@your-vm
codex login

Open the printed URL in your local browser; the OAuth redirect to localhost:1455 travels back through the tunnel to the CLI on the VM, and the login completes as if it were local.

Copy the credential file. Codex stores its login in auth.json under its home directory (CODEX_HOME, which defaults to ~/.codex). The file is not tied to a machine, so a login completed on your laptop can be copied up with scp to the same path on the VM. Treat auth.json as a password-equivalent secret: never commit it or paste it anywhere.

Whichever route you take, the login persists on the VM across reboots, and sessions are saved on the VM's disk, so codex resume works on the box exactly as it does locally.

Step 5: Run every session inside tmux

This is the step that makes the setup worth it. A Codex process launched in a bare SSH session dies when the connection drops; inside tmux, the session belongs to the server, not to your connection:

# Start a named session per task
tmux new -s payments-refactor
codex

# Detach: press Ctrl-b, then d. Close the laptop. Later, from anywhere:
ssh dev@your-vm
tmux attach -t payments-refactor

# See what is running
tmux ls

Name sessions after tasks, not the tool: when you run two or three agents at once, tmux ls should read like a to-do list. One warning: tmux state lives in memory, so a VM reboot clears every session (codex resume recovers the conversations, but not work in flight); anything worth keeping gets committed and pushed. If you run several agents in one repository, give each its own git worktree so they do not fight over the checkout.

When Codex cloud or codex exec is the better answer

Your own VM is not the only way to outlive a laptop. Codex cloud, OpenAI's managed sandbox, runs a delegated task in an isolated container preloaded with your repository and hands back a pull request or a diff; it is the least setup for fire-and-forget work, but there is no live terminal to step into mid-run, and it executes on OpenAI's infrastructure rather than inside your network. And for scripted, recurring jobs on the VM you just built, codex exec runs a task non-interactively, streaming progress to stderr and printing the final message to stdout, which pipes cleanly into cron jobs and CI. The full decision tree, resume semantics included, is in keeping Codex running after closing your laptop.

What this actually costs

The VM is the only new line item: roughly $4 to $24 per month at the providers above. Your Codex usage is billed exactly as before, through the ChatGPT plan or API key you signed in with; running on a server changes nothing about model pricing.

Where a hand-rolled box runs out of road

For one engineer, this setup is genuinely good, and you should run it. The friction appears at the edges. Sharing a live session with a teammate means sharing SSH access to the box, which most teams rightly refuse to do. Parallel tasks need per-task worktrees you script yourself. Nobody sees what the agents are doing without logging in and attaching. And each teammate who wants this repeats the whole ritual, device-auth toggle included, on a box of their own.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. It is this guide's setup, operated as a product. Codex runs as the real CLI (alongside Claude Code, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser: sessions survive a closed laptop and resume from any device, and a teammate can open the same workspace and watch the same live session instead of asking for SSH keys; if the owner approves a control request, the teammate can type into it too. You sign into Codex with your own OpenAI account, and AQ never marks up model usage.

The glue you would otherwise script is built in: every workspace gets an isolated git worktree on a branch named ai/{id}-{slug} with dependencies installed automatically and a one-click rebase onto main, commits and PRs go out under per-user GitHub auth and are tracked per workspace, and each workspace can run a live dev-server preview with shareable links, where comments pinned on the preview can be sent to the agent as prompts. Teams that plan in Linear can label an issue ai-task and a workspace appears with status syncing both ways. There is no shared multi-tenant execution tier: your agents run on your team's machine, with runner health visible in the product.

Pricing is two plans. The Free plan is a personal sandbox for one person: AQ creates a private machine in an isolated network with nothing to install and no time limit, so you skip this guide's setup entirely. Connecting a VM you own, exactly like the one this guide builds, is part of the Team plan at $50 per user per month (early access; standard $200, billed monthly), which also covers a dedicated always-on AQ-managed VM in its own isolated network, with your rate locked for your first 12 months. Solo and comfortable in tmux? Keep the hand-rolled box. AQ earns its place when the second engineer wants in.