Eclipse Enclave: An Open Source Sandbox for AI Coding Agents

Back in 2025, we built an AI agent sandbox so our own developers could run AI coding agents at full autonomy without risking trashing their laptops or leaking secrets. Today, we are happy to announce that this sandbox tool is now available as open source at the Eclipse Foundation, under the name Eclipse Enclave.

Every agent session gets its own container, its own view of the filesystem, and its own network gateway, so you can leave permission prompts off and still know what the agent can (and cannot) reach.

👉 enclave.eclipse.dev · Getting started · github.com/eclipse-enclave/enclave (MIT)

If you would rather see it than read about it, watch the intro video including demos of fully sandboxed sessions below, from enclave to the network allowlist and running multiple session:

AI Coding Agents: Run Them Efficiently or Safely? Or Both?

To get the most out of coding agents, it is best to stop confirming every step they do and let them run terminal commands, install packages, edit files, and iterate until the task is done. But doing that on your host machine is where it gets uncomfortable. Thus, many users of coding agents land on one of three options, and none of them is good:

• Review every command. The agent proposes, you confirm, it runs. Past a certain frequency the interruptions cost more than the agent saves, and each approval prompt pulls you out of the task zone you were actually in.
• Approve everything. After the fifth prompt, the review becomes a reflex. You are now running semi- or even unreviewed commands on the machine that holds your SSH keys, your other repositories, and your customer’s source code, and a poisoned issue comment may trick your agent into doing something you never asked for.
• Restrict the agent. Safer, but it takes away most of what makes the agent useful in the first place.

The first two are really the same option a few weeks apart. Everyone starts out reading each command and ends up rubberstamping them half-reviewed. That leaves restricting the agent, which works, but costs you the reason you wanted an agent in the first place. We made this argument at OCX26, but there wasn’t an easy, off-the-shelf solution openly available… yet.

The obvious answer, a devcontainer or simple docker containers, only covers part of it and adds extra work: setting it up, configuring the workspace mounts, and re-authenticating and re-configuring the agent from scratch every time. It also does not restrict outbound traffic, and it leaves no record of what the agent reached. In summary: friction that everyone tries to avoid.

So We Built A Dedicated AI Agent Sandbox for Ourselves

We did not set out to build a product. In late 2025 we needed a way to let agents run more autonomously without handing them our laptops, so we built sandbox tooling for our own team and called it YOLOArena. Many of our developers have used it every day since, and it got both more useful and more hardened over time: every rough edge got hit by someone who could complain in person or fix it directly.

Then it started “leaking” out of the company. In conversations with partners and clients, in our AI coding trainings, and in customer workshops, people started asking what this sandbox thing was that we were running our agents in. That question came up often enough to make us seriously consider publishing it.

About eight months later, we did, and we found the perfect home for it: the Eclipse Foundation, at enclave.eclipse.dev.

How Enclave Works

Enclave is built around two components: the container that holds an agent session and isolates it from your host machine, and the network gateway that sits in front of it, so every request the agent makes is resolved and proxied against your allowlist.

With that, you just run the command enclave in a project directory to start an isolated agent session and that’s it. Making this easy and frictionless is crucial. Enclave takes care of the rest: building the container with the agent pre-installed, setting up the mounts, caching the agent’s authentication tokens so you log in once instead of on every run, configuring the network, and dropping you into an agent session with the permission prompts already switched off.

Enclave supports Claude Code, Codex CLI, OpenCode, Theia AI, Pi, and Mistral Vibe out of the box, each running in YOLO mode inside its own sandbox. Further harnesses and container features can easily be added as extensions. Docker is the default containerization backend, but there is an experimental QEMU microVM backend in the repository, and we are looking at further options.

One Filesystem View per Session

The agent sees the directory you started from, mounted at the same absolute path as on the host, so paths and builds behave the same inside and outside the container. One level up does not exist as far as the agent is concerned. Your host’s home config and environment are trimmed the same way, so no secrets leak into the container.

Anything else is added on request, and only on request. Mounting a related repository or a reference project next to the one you are working on is a common case, and --add-readonly-dir <path> keeps it read-only when the agent only needs to read it. The same goes for host state: specific environment variables and reviewed agent configuration such as skills are passed through selectively with --pass-env <KEYS> and --host-config passthrough.

Secrets can be declared explicitly so that they show up inside the container only as placeholders, and the gateway swaps in the real credential on the way out. So an agent can call an API it is allowed to call without ever being able to read or leak the secret token. The security notes describe what this covers and what it does not.

The Network Allowlist

All traffic leaves through a gateway sidecar that filters DNS and proxies outbound requests against a domain allowlist. Each agent harness configures its requirements to make them work. For instance, Claude Code reaches the Anthropic API because that domain is on the list; everything else is blocked and logged. When you need more, you can put it on the allow list:

enclave network add-domain eclipsesource.com --global

Worth being precise about the boundary: the allowlist decides which hosts an agent can reach, not what those hosts send back, and Enclave narrows an agent’s access to your machine rather than acting as a runtime escape boundary.

Several Sessions at Once

Sessions are cheap, and three or more in parallel is a normal day for us. Because a session is scoped to the directory you start it in, the natural unit is a git worktree: one branch, one directory, one agent, no collisions between them. This is how we work most of the time:

git worktree add ../myproject-agent -b agent/experiment
cd ../myproject-agent
enclave

Sessions can also run detached, which is what you want when an agent is working on something long and you would rather get on with your own task:

enclave --background --name refactor-parser   # start a detached session
enclave ps                                    # see what is running
enclave attach refactor-parser                # jump back into one

Your Devcontainer, Extended

Enclave does not replace the devcontainer you already have, it wraps it: enclave devcontainer generate takes an existing setup and adds the isolation around it. The tooling a project already declares there is exactly the tooling that lets an agent build the project, run the tests, and check its own work rather than guessing. Enclave ships optional extensions in the same spirit, including a Playwright CLI so an agent can drive a web application it just changed.

Getting Started with Eclipse Enclave

Enclave is available today under the MIT license. It runs on Linux and macOS natively, and on Windows through WSL2. It needs a rootful Docker daemon with buildx; rootless Docker is not supported yet.

🚀 Install Enclave and start your first sandboxed session

🐞 File issues, open PRs, and tell us what does not work: github.com/eclipse-enclave/enclave

⭐ Star the repository and tell someone who runs agents on their laptop

🗂️ Project page at the Eclipse Foundation: enclave.eclipse.dev

The code has been in daily use for months, but as an open source project Enclave is a few weeks old. At this stage stars, issues, and word of mouth genuinely decide how fast it grows, so if it saves you an afternoon, please pass it on.

A graphical companion user interface is in development for those who would rather watch their running agents in a UI than in enclave ps. It groups work into projects and workstreams and shows the state of every session at a glance:

More on that in a future post.

Why It Belongs at the Eclipse Foundation

A sandbox is the piece of your toolchain you have to trust most. It decides which domains your agents may reach, which files they may touch, and what gets recorded about both. That is not something you want to take on faith from a single vendor’s binary, particularly a vendor with its own view on which services your agents should be talking to. It needs to be code you can read, audit, and change, and it needs to outlive whoever wrote it.

That is why we did not simply publish it on GitHub and call it open source. We took it to the Eclipse Foundation, which has spent two decades running open source projects that industry actually relies on, with governance, IP review, and vendor neutrality that hold up under procurement scrutiny. If an isolation layer for AI harnesses is going to become shared infrastructure, that is the kind of home it needs. We are grateful for the support we had along the way, in particular from Thabang Mashologu and his team, who accompanied and helped the open-sourcing from the start.

It also sits well next to the Foundation’s other AI work, such as the AI registry at ai.open-vsx.org. Governing which skills, MCP servers, and plugins a sandboxed session may use is a natural next step, and the two projects will meet there.

Adopting AI Coding Agents Without Losing Control

If you are working out how to bring AI coding into a team without giving up control over what runs where, try Enclave and get in contact with us. Our own path through it is written up in AI (Coding) at EclipseSource: The Internal Story and we are happy to share our experience.

There are two ways to work with us on this. If you want help bringing agents into your own team safely, we do that as training and as hands-on adoption workshp. And if you want Enclave itself to go somewhere specific, that is something you can fund: adapting it to your environment, building the features your teams need, or sponsoring the maintenance that helps a young open source project grow.

👉 AI Coding Training & Guided Adoption

👉 Services for Building AI-Enhanced Tools and IDEs

👉 Sponsored Open Source Development to fund features, adaptations, or long-term maintenance of Eclipse Enclave

👉 Contact us to talk about your AI adoption, or about collaborating on and sponsoring Enclave

⭐ And if you take one thing away from this post: give Enclave a star and help us spread the word

💼 Follow us: EclipseSource on LinkedIn

🎥 Subscribe to our YouTube channel: EclipseSource on YouTube