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.