Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Eclipse Enclave
Eclipse Enclave defines and implements a vendor-neutral runtime for executing AI agents in isolated, policy-controlled environments. The project provides container-based sandboxes for individual agent sessions, network egress policy enforcement, persistent and auditable session lifecycle management, and dashboards for operating many agents across many projects.
In scope:
- Isolation backends for agent execution, starting with Docker containers and potentially extending toward additional mechanisms such as microVMs, rootless runtimes, and Kubernetes-based orchestration.
- Network isolation and policy enforcement, including DNS allowlisting, transparent egress filtering, and request/dependency logging.
- Per-session filesystem and workspace isolation, including integration with source control mechanisms such as Git worktrees.
- Authentication, secret, and credential handling that keeps sensitive material out of agent-visible scope where possible.
- Session lifecycle management: create, pause, resume, attach to, inspect, and clean up agent sessions.
- A desktop and/or web control center for managing multiple agents working across multiple projects in parallel.
- Telemetry, audit trails, and reporting formats that support governance obligations including the EU AI Act and the EU Cyber Resilience Act.
- Extension points for integrating third-party AI agents, IDEs, and editors, including but not limited to those at the Eclipse Foundation.
Out of scope:
- Developing AI agents or large language models. Eclipse Enclave integrates with existing agents (such as Claude Code, Codex CLI, Gemini CLI, OpenCode, Eclipse Theia AI, and others) but does not produce its own.
- Developing an IDE or editor. Eclipse Enclave integrates with editors and IDEs including potential integration with Eclipse Theia, but does not build a new one.
AI coding agents are most useful when they can act autonomously: run commands, install packages, edit files, and iterate without asking for permission at every step. Granting that autonomy directly on a developer's host machine is risky: agents can damage system files, leak secrets, fall victim to prompt injection, or interfere with one another when running in parallel. Most organizations have no consistent way to constrain or audit what their agents actually do.
Eclipse Enclave addresses this gap by providing a sandboxed runtime in which agents operate inside isolated containers (and, in the future, microVMs or other isolation backends) with their own filesystem, process tree, and network stack. A sidecar gateway restricts outbound network traffic to allowlisted domains and records what each agent reached out to. Multiple agents work in parallel without interfering with each other by operating on separate Git worktrees of the same project. Auth, configuration, and history persist across restarts under user control. A control center surfaces the state of all running agents and provides a single place to start, stop, inspect, and review their work.
The same isolation, logging, and policy infrastructure that makes agentic development safer for individual developers also produces the evidence and controls needed by organizations to operate agents responsibly: per-session audit trails, network access logs, dependency provenance records, and policy enforcement points that map to requirements emerging from the EU AI Act and the EU Cyber Resilience Act.
Eclipse Enclave deliberately separates agent execution from agent identity. It treats agents as pluggable workloads behind a common runtime, configuration, and policy surface. This lets the community focus on isolation, observability, governance, and integration — and lets adopters mix and match agents and editors without rebuilding the surrounding infrastructure each time.
Agentic software development is moving fast, and most of the tooling around it is being built either inside individual vendors' product ecosystems or as short-lived community wrappers. There is no vendor-neutral home for the isolation, governance, and operations layer that organizations need in order to use these agents responsibly.
The Eclipse Foundation provides:
- A vendor-neutral governance model that fits a project intended to integrate with many competing AI agents and editors on equal terms.
- An established home for related developer-tooling projects, in particular Eclipse Theia, with which Eclipse Enclave anticipates close integration.
- Strong alignment with European regulatory frameworks (EU AI Act, EU Cyber Resilience Act, GDPR) that increasingly shape how agentic systems must be built, deployed, and audited.
- Mature processes for open specifications, should the project later decide to standardize parts of its policy, telemetry, or extension surfaces.
The intended community is a perfect match with the community of the Eclipse tooling ecosystem and includes:
- Individual developers who want a safe default for running AI coding agents on their own machines without surrendering their host environment.
- Teams and organizations adopting AI agents at scale and needing consistent isolation, observability, and policy controls across projects.
- Regulated organizations and adopters operating under the EU AI Act, EU Cyber Resilience Act, and similar frameworks, who need defensible evidence trails for how agents act on code, data, and dependencies.
- Tool vendors and editor projects (including Eclipse Theia) who want a vendor-neutral runtime in which their agents and IDEs can be safely embedded and controlled.
Eclipse Enclave sits at the intersection of three fast-moving areas: AI tooling, security, and regulatory compliance. Each area is already a central theme in the Eclipse community. Sustaining a vendor-neutral runtime across all three at the pace they are moving requires active collaboration across the ecosystem rather than the work of a single contributor.
EclipseSource is making the initial contribution and bringing the initial committers, but no single organization can carry Eclipse Enclave alone. Its sustainability depends on active engagement from adopters who expect to rely on this runtime in production: through code contributions, working-group participation, sponsorship, knowledge sharing across these areas, and direct collaboration with the project's community.
- Authentication, secret, and credential handling that keeps sensitive material out of agent-visible scope where possible.
- Seamless integration with Eclipse Theia to run Theia's agents transparently in an isolated environment.
- Telemetry, audit trails, and reporting formats that support governance obligations including the EU AI Act and the EU Cyber Resilience Act.
- Extension points for integrating third-party AI agents, IDEs, and editors, including but not limited to those at the Eclipse Foundation.
Initial contribution is planned within a couple of weeks, after we've prepared the source code of our existing internal tooling as a basis for Eclipse Enclave for publishing. Soon after the initial contribution, we plan an initial beta release for Linux-based operating systems.
EclipseSource has developed an initial version of Eclipse Enclave as an internal tools used by several developers on a daily basis. This initial version will be contributed and already includes:
- A Go-based CLI for launching AI coding agents inside isolated Docker
containers. - A gateway sidecar enforcing DNS- and SNI-based network egress policy with
per-request logging. - Git worktree integration for safe parallel agent sessions.
- A desktop control UI (Wails v2 + React) for managing projects, sessions, and worktrees.
- Pluggable tool and feature extensions, with built-in support for Claude Code, Codex CLI, Gemini CLI, OpenCode, Theia AI, and others.
- Per-session authentication, secret, and credential handling, with optional shared- or project-scoped persistence.
- Log in to post comments
AI coding agents are most useful when they can act autonomously: run commands, install packages, edit files, and iterate without asking for permission at every step. Granting that autonomy directly on a developer's host machine is risky: agents can damage system files, leak secrets, fall victim to prompt injection, or interfere with one another when running in parallel. Most organizations have no consistent way to constrain or audit what their agents actually do.
Eclipse Enclave addresses this gap by providing a sandboxed runtime in which agents operate inside isolated containers (and, in the future, microVMs or other isolation backends) with their own filesystem, process tree, and network stack. A sidecar gateway restricts outbound network traffic to allowlisted domains and records what each agent reached out to. Multiple agents work in parallel without interfering with each other by operating on separate Git worktrees of the same project. Auth, configuration, and history persist across restarts under user control. A control center surfaces the state of all running agents and provides a single place to start, stop, inspect, and review their work.
The same isolation, logging, and policy infrastructure that makes agentic development safer for individual developers also produces the evidence and controls needed by organizations to operate agents responsibly: per-session audit trails, network access logs, dependency provenance records, and policy enforcement points that map to requirements emerging from the EU AI Act and the EU Cyber Resilience Act.
Eclipse Enclave deliberately separates agent execution from agent identity. It treats agents as pluggable workloads behind a common runtime, configuration, and policy surface. This lets the community focus on isolation, observability, governance, and integration — and lets adopters mix and match agents and editors without rebuilding the surrounding infrastructure each time.
- Log in to post comments