How to run OpenAI Codex autonomously: local execution with Docker

To run OpenAI Codex autonomously, use Codex CLI's Full Auto mode. In this mode, the agent reads files, writes code, and executes shell commands without asking for permission. It runs with network disabled and sandboxed to the current working directory by default. For proper isolation — especially on shared machines or in CI — wrap it in a Docker container. This gives you filesystem isolation, process isolation, and a disposable environment that can't affect your host system.

There are three practical approaches to running Codex autonomously: Codex's built-in cloud sandboxes (managed by OpenAI, code leaves your machine), manual Docker setup (you build and manage the container yourself), and managed orchestration with Trimo (automated container lifecycle, git workflow, monitoring, and parallel execution). Each approach has different trade-offs around cost, privacy, control, and operational overhead. This guide walks through all three so you can pick the right one for your workflow.

What is Codex Full Auto mode?

Codex CLI provides three operating modes that determine how much autonomy the agent has:

Suggest. The agent proposes changes but doesn't write files or run commands. You approve each action individually. This is the most conservative mode — useful when you want the agent as an advisor, not an executor.
Auto Edit. The agent can read and write files without asking, but must get approval before running shell commands. Good for code generation tasks where you want to review any system interaction.
Full Auto. The agent reads files, writes code, and executes shell commands autonomously. No human approval step. This is the mode you want for unattended, autonomous operation.

In Full Auto mode, Codex applies two safety constraints by default: network is disabled (the agent can't make outbound requests or download packages) and filesystem access is sandboxed to the current working directory and temporary files. These constraints prevent the agent from exfiltrating code or making uncontrolled changes to your system.

On Linux, Codex uses kernel-level sandboxing. On macOS, the sandboxing is lighter. For either platform, running Codex inside a Docker container adds a hard isolation boundary — the container has its own filesystem, process namespace, and network stack, regardless of what the agent tries to do.

The cost problem with Codex cloud sandboxes

Codex's cloud offering runs agents in cloud VMs managed by OpenAI. You submit a prompt, your repository is cloned into a sandbox, and the agent works on OpenAI's infrastructure. The results come back as pull requests or patches.

This is convenient, but it comes with costs beyond API tokens:

Compute costs. Cloud sandboxes consume VM resources that are billed through your subscription tier or usage-based pricing. As you scale to multiple parallel agents or iterative workflows with several runs per feature, these costs compound.
Code leaves your machine. Your source code is uploaded to OpenAI's servers for the duration of the run. For teams with proprietary codebases, compliance requirements, or security policies, this is a non-starter.
Limited environment control. You can't customize the VM image, install specific system dependencies, or configure the runtime environment. The sandbox is what OpenAI provides.
No workflow continuity. Each cloud sandbox is ephemeral. There's no built-in mechanism to chain runs — where the second agent picks up where the first left off, on the same branch, with the same context.

For occasional one-off tasks, cloud sandboxes work fine. For teams running autonomous coding agents at scale — dozens of sessions per day across multiple repositories — local execution eliminates the compute cost entirely. Your hardware is already paid for. The only variable cost is the API tokens.

Running Codex locally in Docker

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

A basic setup looks like this:

# 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 core benefits: code stays on your machine, the agent runs in an isolated filesystem, and network is disabled at the Docker level (not just Codex's application-level sandbox). You control the image, the dependencies, and the runtime environment.

But the manual approach has operational gaps:

No real-time monitoring. You can docker logs -f the container, but there's no structured view of what the agent is doing — which files it's reading, what commands it's running, whether it's stuck.
No parallel execution management. Running five agents simultaneously means managing five containers, five branches, five sets of output. You're building orchestration tooling by hand.
No git workflow automation. You need to handle branch creation, commits, and push logic yourself. If the agent finishes but forgets to commit, or commits to the wrong branch, you lose work.
No pipeline continuity. Chaining runs — where agent B picks up where agent A left off — requires manual branch management and context passing between containers.
No diff review workflow. You get raw container output. Reviewing what actually changed requires manually diffing branches or inspecting the filesystem.

For a single developer running one agent at a time, this works. For anything beyond that, you're rebuilding orchestration infrastructure from scratch.

Managed orchestration with Trimo

Trimo provides managed orchestration for running coding agents in Docker containers on your local machine. It currently supports Claude Code, with Codex support coming soon. The architecture is agent-agnostic — the orchestration layer handles container lifecycle, git workflows, and monitoring independently of which agent runs inside.

Here's what managed orchestration adds on top of raw Docker:

Dispatch agents from a dashboard. Select a repository, write a prompt, and launch. Trimo handles container creation, workspace setup, branch creation, and agent invocation.
Real-time monitoring. Watch agent activity as it happens — file reads, code writes, command execution, test results. Stream output through a web dashboard, not raw terminal logs.
Git auto-commit and safety wrappers. Every change is committed to a dedicated branch. Git wrappers enforce safety rules: no force pushes, no pushes to main, no destructive operations. Changes are always reviewable before merging.
Parallel execution. Run multiple agents simultaneously, each in its own isolated container, each on its own branch. Monitor all of them from a single dashboard.
Pipeline continuity. Chain prompts into multi-step pipelines. The second run picks up where the first left off — same branch, accumulated changes, full context. Iterate on a feature across 3-5 agent runs without manual branch juggling.
Code stays local. Containers run on your machine. Source code is never uploaded anywhere. Only lightweight metadata (run status, events) flows to the cloud dashboard for monitoring.

When Codex support ships, the workflow will be the same: dispatch from the dashboard, monitor in real time, review diffs, iterate with follow-up prompts. The difference is which agent binary runs inside the container.

Comparison

Feature	Codex Cloud	Manual Docker	Trimo
Code stays local	No	Yes	Yes
Docker isolation	N/A (VM)	Yes	Yes
No compute costs	No	Yes	Yes
Real-time monitoring	Limited	No	Yes
Parallel execution	Yes	Manual	Built-in
Git workflow automation	No	No	Yes
Pipeline continuity	No	No	Yes
Dashboard	Yes	No	Yes

Codex cloud is the easiest to start with — no local setup, no Docker knowledge required. Manual Docker gives you full control and privacy but no tooling. Trimo combines local execution with the operational layer that makes autonomous agents practical at scale.

Frequently asked questions

Is Codex Full Auto mode safe?

In Full Auto mode, Codex CLI runs commands with network disabled and filesystem access sandboxed to the working directory. This prevents the agent from reaching external services or modifying files outside the project. Docker adds a harder boundary — filesystem isolation, process namespace separation, and network control at the kernel level. With Trimo, each agent runs in its own disposable container with git safety wrappers that prevent force pushes, destructive operations, and direct pushes to main. Changes are always committed to a branch for review.

Can I use Codex locally without paying for cloud compute?

Yes. Codex CLI is open source and runs entirely on your machine. You pay only for API tokens from your chosen model provider — OpenAI, or any compatible provider that Codex CLI supports. There are no VM costs, no sandbox fees, and no subscription tiers beyond the base API pricing. For teams already paying for API access, local execution adds zero marginal infrastructure cost.

Does Trimo support Codex today?

Trimo currently supports Claude Code as its primary agent. Codex support is on the roadmap and coming soon. The architecture is agent-agnostic — the orchestration layer (Docker container lifecycle, git workflow automation, real-time monitoring, parallel execution) works independently of which coding agent runs inside the container. When Codex support ships, the same dispatch-monitor-review workflow will apply. See the Trimo vs Codex comparison for more on how the two platforms relate.

How does local Codex compare to the cloud version?

Local Codex CLI gives you full privacy (code never leaves your machine), zero compute costs beyond API tokens, and complete control over the execution environment — you choose the OS, system dependencies, and runtime configuration. Cloud Codex gives you managed infrastructure with no Docker or local setup required, but your code is uploaded to OpenAI's servers for processing and you pay for cloud compute on top of API usage. For teams with proprietary code or cost sensitivity at scale, local execution is the stronger choice.

Can I run Codex and Claude Code in parallel?

With Trimo, once Codex support ships, yes. Each agent runs in its own isolated Docker container with its own branch. You could dispatch a Claude Code agent to implement a feature while a Codex agent fixes a bug — both running simultaneously, both monitored from the same dashboard. This is one of the advantages of an agent-agnostic orchestration approach: you pick the best agent for each task rather than being locked into a single provider.