How to run OpenAI Codex autonomously: local execution with Docker

Q: Is Codex Full Auto mode safe?

Full Auto disables network access and sandboxes filesystem writes to the working directory. On Linux, this uses kernel-level sandboxing. On macOS, the enforcement is lighter. Wrapping it in Docker adds a harder boundary — separate filesystem, network namespace, process space. If that still feels too manual, Trimo adds safe git handling and a dashboard on top.

Q: Can I use Codex locally without paying for cloud compute?

Yes. Codex CLI is open source and runs on your machine. You pay for API tokens from your chosen model provider and nothing else.

Q: Does Trimo support Codex today?

Not yet. Trimo currently runs Claude Code. Codex support is on the roadmap. The orchestration layer is agent-agnostic, so when it ships, the same dispatch-monitor-review workflow applies.

Q: How does local Codex compare to the cloud version?

Local gives you privacy (code stays on your machine), no compute costs beyond API tokens, and full control over the environment. Cloud gives you zero setup and managed infrastructure, but your code is uploaded to OpenAI's servers. Both have trade-offs — the right choice depends on whether you value convenience or control.

Codex CLI's Full Auto mode is the most straightforward way to run an AI coding agent unattended. The agent reads files, writes code, and executes shell commands without asking for permission. Network is disabled and filesystem access is sandboxed to the current working directory by default. If you're already comfortable with a terminal, you can be running autonomously in under five minutes.

But "autonomous" doesn't mean "managed." Full Auto handles the coding — it doesn't handle container isolation, branch management, monitoring, or chaining multiple runs into a feature. This guide covers what Codex gives you out of the box, where the gaps show up, and your options for filling them.

What Full Auto actually does

Codex CLI has three operating modes:

Suggest — proposes changes, doesn't execute anything. You approve each action.
Auto Edit — reads and writes files freely, but asks before running shell commands.
Full Auto — reads, writes, and executes without asking. This is the one you want for unattended work.

In Full Auto, two safety constraints apply by default: network is disabled and filesystem access is sandboxed to the working directory and temp files. On Linux, this uses kernel-level sandboxing. On macOS, the enforcement is lighter — something worth knowing if you're running agents on a Mac.

One thing Codex does well here: it supports third-party model providers, not just OpenAI models. If you prefer Claude or a local model, Codex CLI can use it. This is a genuine advantage over tools that lock you into a single provider.

Codex cloud: the easy path (with trade-offs)

Codex's cloud mode runs agents in sandboxes managed by OpenAI. You submit a prompt, your repo is cloned into a sandbox, and the agent works on their infrastructure. Results come back as pull requests or patches.

The honest appeal: it's the easiest way to get started. No Docker, no local setup, no Dockerfile to maintain. Type a prompt, get a PR. For occasional one-off tasks — "update the README," "add input validation to this endpoint" — the simplicity is hard to beat.

The trade-offs show up at scale:

Code leaves your machine. Your source is uploaded to OpenAI's servers for the run's duration. Some teams can't do this — compliance, security policy, or just preference.
Limited environment control. You can't customize the sandbox image, install system dependencies, or configure the runtime. The sandbox is what OpenAI provides.
Cost compounds. Cloud compute is billed through subscription tiers and token usage. A few runs a day is fine. Dozens of runs across multiple repos starts to add up.

None of these are deal-breakers for everyone. If your code is open source, the privacy point is irrelevant. If you run a handful of tasks per week, the cost is negligible. Know your own constraints.

Running Codex locally in Docker

The manual approach: build a Docker image with Codex CLI, mount your workspace, run Full Auto inside the container.

# Dockerfile
FROM node:22-slim
RUN npm install -g @openai/codex
RUN useradd -m codex
USER codex
WORKDIR /workspace

# Run with workspace mounted, network disabled
docker run --rm \
  --network none \
  -v $(pwd):/workspace \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  codex-runner \
  codex --full-auto "Implement the user settings page"

This gives you the important things: code stays local, the agent is isolated from your host filesystem, and network is disabled at the Docker level (a harder boundary than Codex's application-level sandbox). You control the image and dependencies.

What it doesn't give you:

No monitoring. You docker logs -f and hope for the best. With multiple containers, you're tabbing between terminals.
No git workflow. Branch creation, commits, pushes — all manual scripting. If the agent finishes but doesn't commit, you've lost work.
No continuity. Want to send a follow-up prompt? Start a new container, re-clone, checkout the branch, re-mount. The previous run's context is gone.

For a single developer running one agent at a time, this is fine. It's what many of us did before orchestration tools existed, and it works.

Adding orchestration with Trimo

Trimo adds the workflow layer on top of Docker containers. It currently runs Claude Code, with Codex support on the roadmap. The architecture doesn't care which agent runs inside the container — it manages the container lifecycle, git workflow, and monitoring around it.

What you get beyond raw Docker:

Dashboard. Dispatch agents, monitor progress, verify results — from any device.
Git automation. Every change is saved to its own branch. Agents can't mess up your repo. Changes are reviewable before merging.
Parallel execution. Multiple agents in separate containers, separate branches. One dashboard shows them all.
Pipeline continuity. Follow-up prompts build on previous runs — same branch, accumulated commits, full context.
Code stays local. Containers run on your machine. Only metadata flows to the cloud dashboard.

Picking the right approach

There's no single right answer here. Each approach fits a different situation:

	Codex Cloud	Manual Docker	Trimo
Easiest to start	Yes	No	Moderate
Code stays local	No	Yes	Yes
No compute costs	No	Yes	Yes
Multi-provider support	No	Yes (Codex CLI)	Any agent
Monitoring dashboard	Yes	No	Yes
Git workflow automation	No	No	Yes
Pipeline continuity	Limited	No	Yes

Use Codex cloud if you want the fastest path to results and code privacy isn't a constraint. Use manual Docker if you want full control and don't mind scripting the workflow yourself — especially if you're using non-OpenAI models via Codex CLI. Use Trimo if you want the operational layer (monitoring, git automation, parallel execution) without building it yourself.

Frequently asked questions

Is Codex Full Auto mode safe?

Full Auto disables network and sandboxes filesystem access. On Linux, the sandboxing is kernel-level. On macOS, it's lighter. Docker adds a harder boundary on top — separate filesystem, network namespace, process space. With Trimo, git is handled safely — agents can't mess up your repo, and changes always go to a branch for review.

Can I use Codex locally without paying for cloud compute?

Yes. Codex CLI is open source. You pay for API tokens and nothing else.

Does Trimo support Codex today?

Not yet — Claude Code is the supported agent today. Codex support is on the roadmap. The orchestration layer is agent-agnostic, so when it ships, the same workflow applies. See the Trimo vs Codex comparison for more detail.

How does local Codex compare to the cloud version?

Local gives you privacy, zero compute costs, and environment control. Cloud gives you zero setup. Both are valid — the right choice depends on whether you value convenience or control. If you're a solo developer running occasional tasks, cloud is simpler. If you're running agents at scale or have proprietary code, local wins.