wehub-resource-sync
e0e362d700
SDK Tests / SDK CI (push) Blocked by required conditions
SDK Tests / changes (push) Successful in 2m29s
Real E2E Tests / changes (push) Successful in 2m29s
SDK Tests / Python SDK Tests (sandbox) (push) Waiting to run
SDK Tests / CLI Quality (push) Waiting to run
SDK Tests / CLI Tests (push) Waiting to run
SDK Tests / Python SDK Quality (code-interpreter) (push) Waiting to run
SDK Tests / Python SDK Quality (sandbox) (push) Waiting to run
SDK Tests / Python SDK Tests (code-interpreter) (push) Waiting to run
SDK Tests / JavaScript SDK Quality And Tests (code-interpreter) (push) Waiting to run
SDK Tests / JavaScript SDK Quality And Tests (sandbox) (push) Waiting to run
SDK Tests / Kotlin SDK Quality And Tests (sandbox) (push) Waiting to run
SDK Tests / Kotlin SDK Quality And Tests (code-interpreter) (push) Waiting to run
SDK Tests / C# SDK Quality And Tests (code-interpreter) (push) Waiting to run
SDK Tests / C# SDK Quality And Tests (sandbox) (push) Waiting to run
SDK Tests / Go SDK Quality And Tests (push) Waiting to run
Deploy Docs Pages / build (push) Has been cancelled
Deploy Docs Pages / deploy (push) Has been cancelled
Real E2E Tests / JavaScript E2E (docker bridge) (push) Has been cancelled
Real E2E Tests / Python E2E (docker bridge) (push) Has been cancelled
Real E2E Tests / Java E2E (docker bridge) (push) Has been cancelled
Real E2E Tests / C# E2E (docker bridge) (push) Has been cancelled
Real E2E Tests / Go E2E (docker bridge) (push) Has been cancelled
Real E2E Tests / Real E2E CI (push) Has been cancelled
5.1 KiB
5.1 KiB
OpenSandbox Roadmap
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).
Principles
- 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.
Current Focus: 2026 H1-H2
Sandbox Runtime
| 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. |
SDKs and Developer Experience
| 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. |
Observability and Operations
| 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. |
Public Contracts and Governance
| 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. |
Not Currently Planned
- 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.
How Roadmap Items Are Managed
- 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.