[Proposal] Reference implementation for "Local lightweight sandbox" — SkillLite (native OS sandbox, zero Docker)

[EXboys]

Hi OpenSandbox maintainers,

I’m an external developer working on secure execution environments for AI agents. I noticed that “Local lightweight sandbox - Lightweight sandbox for AI tools running directly on PCs” is listed in your official roadmap.

I’ve built an open-source project called SkillLite that implements exactly this use case, and I’d like to propose it as a reference implementation or potential integration candidate for the local sandbox runtime.

Why SkillLite aligns with OpenSandbox’s local sandbox vision:

• ✅ Zero Docker/K8s dependency: Uses native OS sandboxing (Linux: namespaces + seccomp-bpf; macOS: Seatbelt).
• ✅ Ultra-lightweight: Single binary (~1MB), <5ms cold start, minimal memory footprint.
• ✅ Security-first: Blocks dangerous syscalls, network access, file system escapes by default (see security test report).
• ✅ LLM-agnostic: Fully compatible with OpenAI tool-calling protocol — works with any agent framework.
• ✅ MIT licensed, production-ready, and actively maintained.

Suggested collaboration paths:

1. Adopt SkillLite as the “local mode” runtime in OpenSandbox.
2. Define a unified sandbox interface (e.g., via OSEP) that both Docker-based and native runtimes implement.
3. Co-maintain a local-sandbox module under the OpenSandbox org (I’m happy to contribute code/docs).

I’m excited about OpenSandbox’s mission and would love to help accelerate the local sandbox feature. Happy to provide PoCs, benchmarks, or join design discussions!

🔗 Project: https://github.com/EXboys/skilllite
📄 Architecture: https://github.com/EXboys/skilllite/blob/main/docs/en/ARCHITECTURE.md

Thanks for your consideration!

[ninan-nn]

We're currently evaluating solutions for the local lightweight sandbox. We'll take the current proposal into consideration and will keep you updated on any progress : >

[EXboys]

Hi @ninan-nn, thanks for the response and for keeping this on your radar! Totally understand — evaluating the right approach for local sandboxing is important, and I'm glad the proposal is being considered.

Since I opened this issue, SkillLite has continued to evolve with several updates that may be relevant to your evaluation:

• Linux sandbox strengthened: Full seccomp-bpf filter (blocks ptrace, mount, keyctl, kexec, etc.) + rlimit resource limits on both bwrap and fallback paths
• macOS sandbox hardened: Process-exec whitelist (interpreter-only), IPC/Mach port lockdown, fail-closed on sandbox init failure
• Network proxy: SOCKS5 proxy with domain whitelist + IP direct-connect blocking (reverse DNS verification)
• MCP hardening: Request size limits (10MB) + one-time scan_id consumption to prevent replay attacks
• Audit logging: JSONL append-only audit trail covering execution, security events, and network interceptions
• Core architecture refactored: Modular Rust workspace (skilllite-core, skilllite-sandbox, skilllite-executor, skilllite-agent), so the sandbox engine can be used as a standalone crate. This also lays the groundwork for Go / Python / TypeScript SDKs — a Python SDK is already in progress.

Current security score: 8.3/10 across 10 dimensions (up from ~6.5 when I first opened this issue).

A couple of ways I'd be happy to help during your evaluation:

1. Interface alignment — If you're drafting a sandbox interface spec (OSEP or otherwise), I'd love to review and adapt SkillLite's API to conform. Making SkillLite a drop-in "local mode" backend would be a concrete goal.
2. PoC integration — I can build a proof-of-concept showing SkillLite as a local runtime behind an OpenSandbox-compatible interface, to help validate whether the approach fits your architecture.

No pressure at all — just want to make sure the offer stands. I'm genuinely excited about OpenSandbox's vision and happy to contribute in whatever way is most useful, whether that's code, docs, or design feedback.

Looking forward to hearing how the evaluation goes!