Desktop app: devcontainer-like sandbox environment

Related: https://github.com/openai/codex/issues/10450

Yes, we desperately need this if we want to run in "Full access" mode.

Second this even for regular mode - especially in light of all the recent supply chain attacks (axios, lite-llm). Running anything outside of docker is increasingly not possible / risks compromise of the host machine, and just wholesale disallowing npm and uv access in codex would really hamper productivity. Yes you can manually do it through just forcing codex to use docker commands but I haven’t been able to audit that this ensures no direct npm etc commands are run unsupervised in regular mode.

+1️⃣ on this. Native Docker dev container support in Codex Desktop would be a huge step forward.

VS Code already proves this model works well: define your environment in a devcontainer.json or Dockerfile, and all tooling runs transparently inside that container. Codex Desktop could offer the same model as an additional, opt-in execution environment, separate from the existing host sandbox.

Why this matters:

1. Reproducibility: same container image for every developer and CI run, no "works on my machine" issues
2. Dependency isolation: project runtimes (Node, Python, Rust, ...) stay inside the container and don't pollute the host
3. Security: malicious packages (npm, pip, etc.) are contained and can't reach the host filesystem; this also makes Full Access mode actually safe, as @maximedupre pointed out
4. CI parity: the Codex sandbox mirrors the real CI environment, making AI-generated fixes and test runs far more reliable
5. Caching: Docker volumes can persist package caches across sessions without touching the host

The current workaround of manually instructing Codex to use Docker commands is fragile, and there’s no guarantee that direct package manager calls won’t slip through in unsupervised mode.

The current workaround of manually instructing Codex to use Docker commands is fragile, and there’s no guarantee that direct package manager calls won’t slip through in unsupervised mode.

@patrickdobler This is what I've setup and it's actually very dangerous. I think there's a real bug right now because once Codex enters the devcontainer shell, he's not asking for approval anymore. Once the first command to enter the devcontainer has been approved, he can do r/w as he wishes and there's nothing you can do to stop it. This is a massive security hole.

This is how I've instructed him in my AGENTS.md file :

Run every repository command inside one long-lived devcontainer shell. Start it once with: ``sh PATH=/opt/homebrew/bin:$PATH devcontainer exec zsh ``

We’d also like this specifically for Docker Sandboxes.

The Codex CLI can already run well inside Docker Sandboxes, but Codex Desktop currently cannot use a Docker Sandbox as its execution environment unless you do some workarounds with SSH, but it's still fails. Looks like Codex Desktop tries to validate local auth tokens for some reason. These are substituted by Docker Sandbox, so Codex Desktop throws an error:

unexpected status 401 Unauthorized: {"detail":"Could not parse your authentication token. Please try signing in again."}, url: https://chatgpt.com/backend-api/codex/responses, cf-ray: <some-value>, request id: <some-value2>

Docker Sandboxes provide additional value on top of simple docker containers by exposing primitives for controlling egress network and hiding secrets from agents.

This would be amazing for opensource projects. We are trying to create an AI best practises initiative for the Drupal community. The goal is a simple installer that will set up everything you need in a container to have the best experience with AI. Not just skills but everything else running in the container like playwright etc. We have an ecosystem approach for handling containers called DDEV and can already make a plugin for codex cli.

But it would be awesome if I could use the local codex.app gui to manage and interact with the codex cli running inside docker.

It would make pushing community wide adoption better as we could have a consistent environment without worrying what they have already tried themselves with AI.

Absolutely, I would say we desperately need support for remote DevContainers, similar how VS Code is able to do that already - SSH into a remote DevContainer so that Codex development can be done safely on a remote machine inside a desktop.

+1 on this. I've been digging into pretty much this exact idea recently on the GitHub Copilot / VS Code side as well. I've attached my 2c to those as well as the thought I have and that I've spent the last 2 days thinking about as I'm actually experiencing scenarios where I would've loved to use Dev Containers for my agent sessions already! :)

The bit I'd really love to see is Dev Containers becoming an actual local execution option for Codex sessions, rather than just a way of running the CLI manually inside a container.

Something roughly like:

Codex App -> Worktree -> Dev Container -> Codex

The App can stay as the UI / control surface, but the agent's shell commands, package installs, builds, tests and project tooling all happen inside the Dev Container instead of directly on my normal machine.

Where I think this gets especially useful is when you combine it with Docker Compose.

If the project needs Postgres, Redis, a queue, LocalStack or whatever else, bring those services up as part of that session's environment too.

Then you could have something like:

Session A -> Worktree A -> Dev Container A -> Postgres A

Session B -> Worktree B -> Dev Container B -> Postgres B

So, each parallel agent effectively gets its own little development environment instead of sharing my normal dev stack or interfering with another agent session.

That's also where this starts making a lot of sense to me from the sandbox side.

I'd be far more comfortable giving an agent more freedom to install packages, run migrations, change configuration, experiment with things, etc. if the environment it's allowed to mess up is disposable.

If it wrecks its container or database, that's fine. Tear it down and rebuild it. I'd rather have that boundary than give an autonomous agent broader access to my actual host machine.

In my head it's basically local-first Codespaces for agents.

The repo already describes the environment using devcontainer.json / Docker Compose, my machine provides the compute, and the Codex App manages the sessions.

Ideally Codex could detect an existing .devcontainer configuration when I start a session and let me choose it as the execution environment.

Longer term, reusable user-defined Dev Container templates could also be really useful for repositories that don't ship their own config, but honestly even just supporting an existing .devcontainer + Compose setup would cover most of what I'm after..

VS Code is actually starting to implement a very similar idea for its Agent Host now as well:

microsoft/vscode#317380
microsoft/vscode#331934

It feels like there's a really useful execution model emerging here for local agent workflows and the different harnesses and tools seem to be converging on the idea of using Dev Containers for this! :D