MXC - a sandboxed code execution system

📝 Discussion Summary (Click to expand)

Prevalent Themes in the Discussion

Redundant effort – many teams are building essentially the same sandbox/min‑runtime for AI agents

“Everyone has been building a harness/sandbox the last 6 months. I’ve seen dozens and dozens shared in discords.” – lifeisloving
“Why is everyone making their own code execution agent runtime engines …” – minraws
Security concerns – doubts about the robustness of ad‑hoc sandboxes and fear of widespread vulnerabilities

“I feel like there are more vulnerabilities in this vibe‑coded slop sandboxes, and it’s more likely everyone … will shoot our foot off once a CVE is hit …” – minraws
“I’d be way more confident building upon something I can grasp and understand.” – kernc
Cross‑platform compatibility – the need for a solution that works across Windows, macOS, and Linux

“Different use‑cases have different requirements. e.g. this one puts multi‑platform support as a high requirement, a requirement that OpenShell doesn’t fulfil.” – hobofan
“The problem with OS level sandboxes … is that relying on OS/hardware features means your TAM shrinks …” – torginus

🚀 Project Ideas

Generating project ideas…

A declarative policy language that lets developers describe sandbox constraints (filesystem, network, device, syscall) once and compiles them to multiple backends (bubblewrap/seatbelt on Linux, Job objects/WSL on Windows, sandboxed processes on macOS).
Core value: eliminates duplicated sandbox implementations and provides a single source of truth for cross‑platform agent isolation.

Key	Value
Target Audience	Developers building AI coding agents, CI runners, or any tool that needs secure, configurable execution environments.
Core Feature	Policy DSL → backend‑specific configuration generator (supports bubblewrap, seatbelt, Windows Job objects, macOS Sandbox).
Tech Stack	Rust (core compiler), WASM for optional web‑based policy editor, CI integration via GitHub Actions.
Difficulty	Medium
Monetization	Hobby

HN users complained about “everyone making their own code execution agent runtime engines” and wished for a “bare minimum subset common amongst them” (minraws). SPC directly addresses that by offering a shared policy layer.
rock_artist’s desire for “permission logic for delegating” and a “unified agreed concept” fits the DSL approach.
Potential to spark discussion on standardizing sandbox policies, similar to how OpenPolicy Agent unified policy enforcement.

A terminal‑based dashboard that runs alongside a sandboxed agent, displaying blocked syscalls, file accesses, and network attempts in real time, allowing the user to grant or revoke permissions without stopping the agent.
Core value: provides the dynamic, revocable permission model that neobrain asked for, reducing “press okay” friction while maintaining security.

Key	Value
Target Audience	Power users, agent developers, and security‑conscious engineers who run untrusted code or AI agents locally.
Core Feature	Live monitoring UI + hot‑key permission toggles that update the underlying sandbox (e.g., via seccomp BPF updates or bubblewrap flags).
Tech Stack	Ratatui (Rust TUI library) + Rust sandbox crate (or interface to existing MXC/sandbox‑run).
Difficulty	Medium
Monetization	Hobby

neobrain’s comment: “Ideally the sandbox would be able to aggregate blocked accesses and then expose them in an external TUI dashboard, where I can then enable access (without blocking any running agent…)”. LivePerm directly implements this idea.
The tool would appeal to commenters who currently give agents “full permission on each thread” (mintflow) but want finer‑grained control.
Could become a reference implementation for dynamic permission handling, inspiring further sandbox‑UX discussions.

A minimal, auditable sandbox executor written in safe Rust that provides a “learning mode” to auto‑generate the least‑privilege policy needed for a given workload, then locks it down for subsequent runs.
Core value: replaces brittle DIY bash sandboxes (like sandbox‑run) with a trustworthy, easy‑to‑audit runtime that still offers convenient policy discovery.

Key	Value
Target Audience	Developers who have rolled their own sandbox scripts and seek a secure, drop‑in replacement (e.g., users of sandbox‑run, slopbox, or custom bash wrappers).
Core Feature	Run a command in a locked‑down namespace; optionally observe and record required resources to produce a reusable policy file.
Tech Stack	Rust (sandboxing via nix crate, seccomp, capabilities), CLI built with clap, optional TOML policy format.
Difficulty	High (due to security correctness)
Monetization	Hobby

dannyw criticized sandbox‑run as “600 lines of dense Bash” with critical security flaws, saying they’d “trust 350k lines of Rust way more than that!” (IshKebab). SSR offers a Rust‑based alternative that is both smaller and more reliable.
minraws expressed worry about “vibe coded slop sandboxes” and shared vulnerabilities; SSR’s focus on minimal TCB and formal testing mitigates that risk.
Provides a concrete target for HN discussion on sandbox correctness and could become a foundation for other tooling (e.g., the policy compiler or LivePerm).