Can OpenAI Codex run GPU jobs, and how do you set it up?

OpenAI Codex can run GPU jobs, but not on its own hardware: it launches them through an MCP server that talks to a compute platform. On Nodus, two Codex CLI commands let Codex estimate, launch and follow GPU jobs on your account, and nothing is created until you accept a cost estimate. Raise one Codex timeout and turn on approvals for write tools, and the setup is ready for jobs that run longer than a minute.

This post is the Codex-specific version of our MCP setup guide for coding agents. It covers what that guide skips: which Codex surface to use, the config.toml settings that matter for long jobs, and how to size a spending cap for work Codex starts. The settings come from reading the current Codex MCP docs against the Nodus MCP tool reference.

Does Codex come with GPUs?

No, and none of its surfaces promise one. The Codex CLI, the IDE extension and the ChatGPT desktop app run Codex on your machine. Codex cloud tasks run in a container, by default the codex-universal image, and OpenAI's cloud environment docs describe languages, packages and setup scripts, not GPU access.

So the practical question is how Codex reaches a GPU somewhere else. The answer is a tool it can call. MCP is the standard way to give Codex tools. The Codex MCP docs say the ChatGPT desktop app, the Codex CLI and the IDE extension share one MCP configuration on the same machine. Add Nodus once and all three can launch GPU work.

Which Codex surface should launch GPU jobs?

Launch GPU work from a local Codex host: the CLI, the IDE extension or the ChatGPT desktop app. OpenAI's docs describe direct MCP connections for local Codex clients, while ChatGPT on the web reaches remote MCP tools through plugins.

Codex cloud tasks are a poor fit for this today. OpenAI's docs say agent internet access is off by default in cloud tasks, and secrets are removed before the agent phase starts. Both work against an agent that needs to reach a compute API with your credentials. We let cloud tasks write and test the training code, then launch the run from a local session.

Checked November 5, 2026 against the Codex MCP, cloud environment and internet access docs.

How do you add Nodus to Codex?

Use the hosted server if your code already lives in a container image, and the local server if Codex should upload your project. These commands are copied from the Nodus connect page.

Hosted server, signed in through your browser:

codex mcp add nodus --url https://api-next.nodus-compute.ai/mcp
codex mcp login nodus

Local server, which runs on your machine and uses your nodus login:

codex mcp add nodus -- nodus mcp

The difference matters more in Codex than it looks. The Nodus MCP guide says only the local server has upload_source, download_output and cp, the tools that touch your machine's files. The hosted server cannot read your laptop. If you want to say "train this repo on an H100" and have Codex ship the code, use the local server.

On a remote box with no browser, the Codex docs say codex mcp login nodus --no-browser prints a URL to open elsewhere. Then paste the redirect URL back into the terminal.

Which config.toml settings matter for GPU work?

Two settings do most of the work: the tool timeout and the approval mode. Codex keeps MCP servers in ~/.codex/config.toml under [mcp_servers.<name>], and both settings are documented in the Codex MCP docs.

The timeout is the easy one to miss. Codex gives every MCP tool call 60 seconds by default (tool_timeout_sec).

Nodus's wait tool waits up to 60 seconds for a state change, which leaves no room for network time. Its exec tool runs a command inside a running Job for up to 300 seconds, five times the default. At the default, a long exec can be cut off by Codex before Nodus finishes.

At the 60-second default, a Nodus exec call can run five times longer than Codex will wait.

We set 330 seconds: the 300-second exec limit plus 30 seconds of headroom. For the hosted server, the entry looks like this:

[mcp_servers.nodus]
url = "https://api-next.nodus-compute.ai/mcp"
tool_timeout_sec = 330
default_tools_approval_mode = "writes"

[mcp_servers.nodus.tools.apply]
approval_mode = "prompt"

The approval lines are the second half. The Codex docs say writes mode prompts for any tool the server does not mark read-only, and a per-tool prompt forces a question every time. We pin apply to prompt because it is the tool that creates paid work.

Nodus adds its own check on top. The first apply call only returns a dry run with an estimated cost and an etag, and the create fails if the estimate changed before you confirm. The Nodus guide is clear that other write tools, including delete, exec and set_state, skip that handshake. That is why we keep Codex's approvals on for them too.

How much should you let a Codex-launched job spend?

Give every job Codex creates a maxCostUSD cap sized to the run, not one big number for everything. The Budgets guide says a Job never holds more than its cap. At the cap it checkpoints and suspends with reason MaxCostReached, and raising the cap resumes it from that checkpoint.

The same dollar cap means very different run times on different hardware. At the rates listed on the Nodus pricing page (L4 $0.430/hr, A100 80GB $1.090/hr, H100 SXM $2.600/hr), a $25 cap lasts:

Prices checked November 5, 2026 on the Nodus pricing page. Hours = $25 / hourly rate.

A cap that is generous for a single L4 stops an 8 x H100 run after about 72 minutes.

Our rule: cap = hourly rate x the hours you expect x 1.25. A 3-hour run on one H100 gets $2.60 x 3 x 1.25 = $9.75. If Codex hits the cap, the job suspends with its checkpoint instead of failing, and you decide whether to raise it. Put the rule in your project's AGENTS.md so Codex applies it without being reminded:

When creating Nodus Jobs: always set maxCostUSD = hourly rate x expected hours x 1.25,
show me the estimate before apply, and never raise a cap without asking.

For a hard ceiling across everything Codex does, add a project Budget as well. Our post on GPU spending limits for AI agents walks through that setup.

What does a first Codex GPU job look like?

Start with a job small enough that a mistake costs cents. The Nodus quickstart uses one L4, a $1 cap and a 10-minute timeout, and the MCP guide suggests a prompt in the same spirit. In Codex, with the local server connected, we ask:

Prepare a Nodus Job for train.py on one L4 with a 10-minute timeout and a
maximum cost of $1. Show me the source that will be uploaded and the estimate.
Wait for my approval before creating anything, then follow the Job and
download its output when it succeeds.

Codex should call whoami, read the Job schema with explain, upload the source and return the dry run. After you approve, it follows the job with wait and logs. At $0.43/hr, ten minutes on an L4 costs about seven cents. The Nodus guide also says logs come back marked untrusted, so text a program prints cannot act as a new instruction to Codex.

FAQ

Can Codex use Nodus without the MCP server?

Yes. Codex can run shell commands, so with network access allowed in its sandbox it can call the Nodus CLI (nodus run ... --dry-run) like any other tool. MCP is the better route because tools are scoped by the grant you approve, and apply adds the estimate handshake.

Does the Codex sandbox block the Nodus connection?

No. OpenAI's approvals and security docs say the network proxy for sandboxed commands does not filter MCP server connections. A sandbox with network access off can still reach the Nodus server, which is why the approval settings above matter.

How do I take access away from Codex?

Delete its grant in the Nodus console under Settings, Connected agents, or with nodus delete oauthgrant <name>. The Nodus MCP guide says narrowing or deleting a grant takes effect within 30 seconds, even for a client that already holds a token.

Can I limit which Nodus tools Codex can see?

Yes, in two places. On the Nodus consent page you choose scopes, and a client granted only jobs:read sees only the tools that read Jobs. In Codex, enabled_tools and disabled_tools in the server's config.toml entry act as an allow list and a deny list.

Originally published on the Nodus blog.