{"slug": "claude-code-codex-in-docker-sandboxes-more-autonomy-less-risk", "title": "Claude Code + Codex in Docker Sandboxes: More Autonomy, Less Risk", "summary": "Docker Sandboxes now allow Claude Code and Codex coding agents to run with full autonomy inside isolated microVMs, reducing the risk of granting --dangerously-skip-permissions or --dangerously-bypass-approvals-and-sandbox on a developer's host machine. The setup, documented by Docker, enables agents to install packages, use sudo, and run Docker without host access, improving iteration speed for tasks like browser testing and multi-service environments.", "body_md": "Coding agents now take up a large part of my development workflow.\n\nI use Claude Code mostly for a work project. For personal projects, experiments, and learning, I spend much more time with Codex.\n\nThey work best when I give them clear requirements, constraints, an expected result, and a reliable way to verify that result.\n\nWith that in place, the agent can handle most of the implementation loop itself: inspect the code, make changes, run tests, fix failures, and continue until the task is done.\n\nPermissions are where this workflow usually slows down.\n\nI already allow a small set of commands that I consider safe and predictable. That removes many unnecessary approvals, but larger tasks eventually need something outside that list.\n\nClaude Code and Codex can skip those approvals entirely with --dangerously-skip-permissions and --dangerously-bypass-approvals-and-sandbox.\n\nI wouldn’t run either of these modes directly on my development machine. The whole point is to move that level of access into a separate environment where the agent can work freely without getting the same access to the rest of my laptop.\n\nClaude Code and Codex already include their own permission and sandboxing mechanisms. Docker Sandboxes don’t replace them. They move the boundary one level out by running the entire agent inside an isolated machine.\n\n```\nmore restrictions → safer machine, less autonomyfewer restrictions → more autonomy, larger blast radius\n```\n\nDocker Sandboxes let me move that trade-off outside the agent.\n\nDocker Sandboxes run the coding agent inside an isolated microVM with its own Linux environment and Docker Engine.\n\nInside that environment, the agent can install packages, use sudo, start services, run Docker, break something, fix it, and try again.\n\nI expose only the project and integrations required for the task.\n\n```\nMy laptop│├── credentials├── other repositories├── host Docker│└── Docker Sandbox    ├── Claude Code / Codex    ├── Linux    ├── sudo    ├── private Docker Engine    └── project workspace** In direct mode, the workspace is mounted from the host.\n```\n\nThat machine exists for the agent.\n\nFrom a project directory, I can start Claude Code with:\n\n```\nsbx run claude\n```\n\nor Codex with:\n\n```\nsbx run codex\n```\n\nDocker starts them in a mode that allows them to execute commands without stopping for approval each time.\n\nThat is pretty much the point.\n\nI won’t turn this article into an installation guide. The [Docker Sandboxes documentation](https://docs.docker.com/ai/sandboxes/) already covers installation, networking, credentials, ports, and configuration.\n\nThe more useful question is where this setup improves day-to-day development.\n\nMany development tasks need several iterations.\n\nThe agent reads the code, tries an implementation, runs the tests, finds another issue, changes the implementation, and tests again.\n\nIf I already defined the requirements and validation criteria, I don’t want the whole process to depend on me being there every few minutes.\n\nI want to give it the task, let it keep working, and review the result afterward.\n\nBrowser testing often expands the environment requirements of an otherwise simple task.\n\nThe agent may need Playwright, browser binaries, system packages, a running application, screenshots, and several rounds of testing.\n\nI don’t want to install all of that on my laptop just because the agent needs it for one task.\n\nInside a sandbox, it can install whatever it needs.\n\nThose dependencies stay inside the environment created for the agent.\n\nThis works well for experiments too. The agent can try a package, change a system dependency, or install another tool without changing my local development setup.\n\nMany projects need more than application code.\n\nA typical development environment might include a database, Redis, queues, background workers, or several services managed through docker compose.\n\nGiving an agent access to Docker means it can set up and test that environment itself.\n\nGiving it access to my host Docker daemon is a different decision.\n\nDocker Sandboxes provide a separate Docker Engine inside the sandbox.\n\nThe agent can build images, start containers, remove them, recreate the stack, and experiment without touching the Docker environment running on my laptop.\n\nThat separation is especially useful when I want the agent to keep working without me watching every step.\n\nFor small interactive tasks, letting the agent edit my current working tree is usually fine.\n\nFor larger tasks, I prefer clone mode:\n\n```\nsbx run --clone claude\n```\n\nThe sandbox gets its own copy of the repository. The agent can modify it independently without changing my local working tree.\n\nAfterward, I review the result and decide which changes I want to bring back.\n\nI like this model much more for larger tasks.\n\nIt feels closer to delegating work to another developer: I care about the requirements and the result, not about watching every file change as it happens.\n\nUseful coding agents eventually need access to tools outside the repository.\n\nThat might include GitHub, internal APIs, package registries, or other development services.\n\nThe agent should get only the capabilities required for the task. It shouldn’t automatically receive every credential available on my machine.\n\nDocker Sandboxes can keep supported credentials on the host while allowing the sandbox to use the corresponding integration.\n\nThe agent gets the capability it needs.\n\nIt doesn’t necessarily need the secret itself.\n\nIsolation doesn’t make generated code correct.\n\nAn agent can misunderstand a requirement, make a poor architectural decision, introduce a subtle regression, or produce code that passes the tests while still solving the wrong problem.\n\nI still review its work.\n\nSandboxes also add some overhead. Each one has its own environment, dependencies, tools, and Docker images.\n\nThe level of isolation also depends on how I run the sandbox.\n\nIn direct mode, the project workspace is shared with the sandbox, so the agent can modify those files directly.\n\nClone mode creates a separate copy of the repository. I prefer that for larger tasks because the agent can work freely without touching my local working tree.\n\nThe sandbox mainly limits the damage a mistake can cause.\n\nIt doesn’t remove the need for good requirements, tests, or code review.\n\nMy workflow with coding agents hasn’t changed much at the beginning or the end of a task.\n\nI still define the requirements, provide context, specify how the result should be validated, and review the final changes.\n\nDocker Sandboxes change the part in the middle.\n\nClaude Code or Codex can install what they need, run services, use Docker, execute tests, fail, retry, and continue working without waiting for me to approve every step.\n\nThat makes coding agents much more practical for larger development tasks while keeping their working environment separate from the rest of my laptop.\n\n*Originally published at **https://liakhov.dev** on August 11, 2026.*\n\n[Claude Code + Codex in Docker Sandboxes: More Autonomy, Less Risk](https://blog.stackademic.com/stop-babysitting-coding-agents-give-them-their-own-machine-8ef7a5efab4a) was originally published in [Stackademic](https://blog.stackademic.com) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/claude-code-codex-in-docker-sandboxes-more-autonomy-less-risk", "canonical_source": "https://blog.stackademic.com/stop-babysitting-coding-agents-give-them-their-own-machine-8ef7a5efab4a?source=rss----d1baaa8417a4---4", "published_at": "2026-08-14 07:07:29+00:00", "updated_at": "2026-08-14 07:20:18.664540+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["Docker Sandboxes", "Claude Code", "Codex", "Docker"], "alternates": {"html": "https://wpnews.pro/news/claude-code-codex-in-docker-sandboxes-more-autonomy-less-risk", "markdown": "https://wpnews.pro/news/claude-code-codex-in-docker-sandboxes-more-autonomy-less-risk.md", "text": "https://wpnews.pro/news/claude-code-codex-in-docker-sandboxes-more-autonomy-less-risk.txt", "jsonld": "https://wpnews.pro/news/claude-code-codex-in-docker-sandboxes-more-autonomy-less-risk.jsonld"}}