Last updated: 2026-04-28
This roadmap describes the intended project direction for roughly the next 12
months. It is a planning guide, not a release commitment. Implementation details
are tracked through GitHub Issues, pull requests, and OpenSandbox Enhancement
Proposals (OSEPs).
- Keep public API contracts, SDKs, CLI behavior, implementation, examples, and
documentation aligned.
- Prefer additive, backward-compatible changes for public interfaces.
- Use the OSEP process for major architecture, API, runtime, or security-model
changes.
- Keep roadmap items focused on project direction instead of using this file as
a full backlog.
- Move completed work into release notes, OSEP status, or stable documentation
instead of keeping long historical task lists here.
| Area | Status | Tracking | Notes |
|---|
| Local lightweight sandbox | Planned | TBD | Lightweight sandbox runtime for AI tools running directly on PCs. |
| Persistent volumes | Implementing | OSEP-0003 | Close remaining runtime/backend gaps from OSEP-0003 before treating volume support as mature. |
| Secure container runtime | Maturing | OSEP-0004, secure container guide | Continue hardening isolation guidance and deployment practices. |
| Pause and resume via rootfs snapshot | Implementing | OSEP-0008 | Improve lifecycle support for stateful sandbox workflows. |
| Secure endpoint access | Implemented / maturing | OSEP-0011 | Keep endpoint security behavior aligned across server, SDKs, and docs. |
| Area | Status | Tracking | Notes |
|---|
| SDK parity | Ongoing | sdks/, specs/ | Keep Python, Go, Kotlin, JavaScript/TypeScript, and C# SDKs aligned with public specs. |
| Client-side sandbox pool | Implementing / maturing | OSEP-0005 | Expand behavior consistency, tests, and documentation where practical. |
| CLI usability | Planned | cli/ | Improve common sandbox lifecycle workflows and developer ergonomics. |
| Developer console | Implementable | OSEP-0006 | Provide a clearer operational surface for sandbox users and maintainers. |
| Area | Status | Tracking | Notes |
|---|
| OpenTelemetry metrics and logs | Implementing | OSEP-0010 | Add observability across execd, ingress, and egress. |
| Agent in-sandbox audit trail | Planned | TBD / OSEP needed | Define auditable records for agent actions inside sandboxes, such as command/session execution, file operations, network access, identity context, retention, and privacy boundaries. |
| Kubernetes deployment | Ongoing | kubernetes/, Helm charts | Keep self-hosted deployment, chart, and operational documentation current. |
| Network isolation guidance | Ongoing | network isolation guide | Continue documenting safe defaults and practical isolation patterns. |
| Area | Status | Tracking | Notes |
|---|
| Lifecycle API stability | Ongoing | specs/, OSEPs | Preserve compatibility and require clear migration paths for user-visible changes. |
| Security documentation | Ongoing | SECURITY.md, docs/ | Keep vulnerability reporting, security expectations, and deployment guidance current. |
| Open project governance | Ongoing | GOVERNANCE.md, CONTRIBUTING.md | Maintain a lightweight, public decision process as the project grows. |
- Declaring a stable v1 API before lifecycle semantics, runtime behavior, and
SDK compatibility are mature enough to support it.
- Breaking public specs, SDK interfaces, CLI behavior, or documented workflows
without an OSEP and migration path.
- Provider-specific features that cannot be documented, tested, or isolated
cleanly from the public API surface.
- Heavy release-train governance before the project has enough maintainer
capacity to keep that process current.
- Small work is tracked as GitHub Issues and pull requests.
- Major features, architecture changes, public API changes, runtime behavior
changes, and security-model changes start with an OSEP.
- Active roadmap entries should link to an issue, PR, OSEP, or documentation
page once a stable tracking location exists.
- Completed work should be reflected in release notes, implemented OSEPs, and
user documentation rather than remaining as an active roadmap item.
- Maintainers should review this file at least quarterly, or whenever a major
OSEP changes status.