Run OpenAI Codex CLI on a remote machine
Updated October 24, 2026 .md
Short answer: Start a cloud VM where Codex CLI is already installed, sign in with codex login --device-auth or an API key, and run codex or codex exec there. On Sandboxer, sbx new gives you that VM in seconds, and you can also send Codex tasks from your laptop with sbx prompt --provider codex.
At a glance#
| Topic | Detail |
|---|---|
| Codex CLI | Preinstalled in every sandbox (codex-cli 0.163.0 when we checked) |
| Sign-in options (OpenAI's docs) | Device code, API key, copy ~/.codex/auth.json, or forward the login callback on port 1455 |
| Unattended runs | codex exec "…", read-only by default; add --sandbox workspace-write to allow edits |
| From your laptop | sbx prompt <id> --provider codex "…" with your OpenAI key on the dashboard's Agents page |
| Machine | default: 4 vCPU, 8 GB RAM, 50 GB disk, $0.036/hour, billed per second, free while stopped |
1. Create the VM#
curl -fsSL https://sandboxer.com/install | sh # installs sbx and signs you in
sbx new
sbx exec sb_k3v9x2mq "codex --version"2. Sign in to Codex on the VM#
OpenAI's authentication docs list these methods for remote and headless machines. Pick one.
Device code (OpenAI's preferred method for headless machines; beta). First enable device code login in your ChatGPT security settings, or ask your workspace admin to. Then:
sbx ssh sb_k3v9x2mq
codex login --device-auth # open the link on your laptop and enter the codeAPI key, for scripts and CI:
sbx ssh sb_k3v9x2mq -- bash -lc 'printenv OPENAI_API_KEY | codex login --with-api-key'This needs OPENAI_API_KEY set inside the VM, for example with sbx new -e OPENAI_API_KEY="$OPENAI_API_KEY".
Copy your existing login. If you've already run codex login on your laptop, copy the auth cache. OpenAI's docs say to treat this file like a password, because it contains access tokens.
sbx exec sb_k3v9x2mq "mkdir -p ~/.codex"
sbx scp ~/.codex/auth.json sb_k3v9x2mq:/home/user/.codex/auth.jsonForward the login callback. Codex's browser login calls back to localhost:1455. Forward that port from your laptop to the VM, then run codex login in the VM and open the printed address on your laptop:
sbx forward sb_k3v9x2mq --remote 1455 --local 1455 # stays open until Ctrl+C; use a second terminal for codex login3. Run it#
Interactively, in a tmux session so it survives a dropped connection:
sbx ssh sb_k3v9x2mq
tmux new -s codex
codexUnattended, with codex exec. It prints progress to stderr and only the final message to stdout. It's read-only unless you allow edits:
sbx exec sb_k3v9x2mq --detach --cwd my-repo \
"codex exec --sandbox workspace-write 'Fix the failing tests and commit on a branch'"OpenAI's docs say to use --sandbox danger-full-access "only in a controlled environment (for example, an isolated CI runner or container)". A sandbox VM started with --no-env and only the key it needs is that kind of environment. If you copied your auth.json in, remember the agent can read those tokens too; prefer a dedicated API key there.
4. Or drive it from your laptop#
Add your OpenAI key on the dashboard's Agents page once. Then send Codex tasks without opening a shell, and follow its events:
sbx prompt sb_k3v9x2mq --provider codex "Refactor the auth module and add tests"
sbx events sb_k3v9x2mq --followKeep it running, or pause it#
sbx extend sb_k3v9x2mq --hours 12 # a new sandbox auto-stops after 1 hour
sbx stop sb_k3v9x2mq # saves memory and disk; free while stopped
sbx resume sb_k3v9x2mq # the tmux session and codex are still runningFAQ#
How do I log in to Codex CLI over SSH?#
Use codex login --device-auth, which OpenAI recommends for headless machines. The alternatives are an API key (printenv OPENAI_API_KEY | codex login --with-api-key), copying ~/.codex/auth.json, or forwarding port 1455 for the browser callback.
Can I use my ChatGPT plan instead of an API key?#
Yes, when you sign in yourself on the VM with device code, the copied auth cache or the forwarded callback. For sbx prompt, add an OpenAI API key on the dashboard's Agents page.
Does codex exec change files by default?#
No. OpenAI's docs say codex exec runs in a read-only sandbox by default. Pass --sandbox workspace-write to let it edit files.
Is --full-auto still supported?#
No. OpenAI's docs say --full-auto is no longer supported, and point to --sandbox workspace-write instead.
What does the VM cost?#
The default size is $0.036 an hour, billed per second, and nothing while stopped. OpenAI bills model usage separately.
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.