Add exec-sandbox deployment (self-hosted QEMU microVMs)

[clemlesne]

Add exec-sandbox deployment (self-hosted QEMU microVMs)

Summary

Proposing exec-sandbox as a new AbstractDeployment backend for SWE-ReX. It runs code in ephemeral QEMU microVMs with hardware-level isolation (KVM on Linux, HVF on macOS) — self-hosted, no cloud account needed.

Why

• Self-hosted — ModalDeployment and FargateDeployment require cloud accounts. DockerDeployment requires Docker. exec-sandbox runs on bare metal with just QEMU. Data never leaves the machine.
• macOS + Linux — HVF on macOS, KVM on Linux. Docker alternative for macOS dev machines without Docker Desktop.
• Fast — ~1-2ms from warm pool, ~200ms from memory snapshots.
• VM isolation — Hardware-level boundary vs Docker process isolation.
• Apache-2.0

How it maps

exec-sandbox is a Python library with an async API. Following the Daytona deployment pattern (PR #191):

class ExecSandboxDeploymentConfig(BaseModel):
    type: Literal["exec_sandbox"] = "exec_sandbox"
    language: str = "raw"
    memory_mb: int = 512

    def get_deployment(self) -> AbstractDeployment:
        from .exec_sandbox import ExecSandboxDeployment
        return ExecSandboxDeployment.from_config(self)

The deployment would:

1. start() — Boot a QEMU microVM via Scheduler.session(), then start the swerex-remote server inside it via session.exec()
2. stop() — Close the session (VM is ephemeral, auto-destroyed)
3. runtime — Return a RemoteRuntime connected to the swerex-remote server inside the VM
4. is_alive() — Check VM + runtime health

The key question is how to expose the swerex-remote HTTP server running inside the VM. exec-sandbox supports port forwarding via expose_ports, which could map the server port to the host.

Open questions

• Port forwarding — swerex-remote needs an HTTP endpoint reachable from the host. exec-sandbox's expose_ports feature can handle this, but the exact wiring needs validation.
• Base image — The swerex-remote binary would need to be available inside the VM. Options: pre-bake it into the QEMU image, or pip install at session start.

Links

• Repo · PyPI
• Reference PR: feat: add daytona deployment #191 (Daytona deployment — same integration pattern)

Happy to submit a PR if there's interest.

[Keesan12]

An exec sandbox is a big step, but the operator experience matters just as much when the sandbox says no. A permission failure, an unsupported command, and a broken task should not all collapse into "the agent failed."

I'm building MartinLoop because teams need to understand and trust the work their coding agents actually do. We wrap a run with limits and verification, then leave a clear receipt of the outcome and the reason it stopped. The point is not more process for its own sake. It is being able to hand an agent real work without losing the ability to explain or recover from the result.

Would be curious which sandbox rejections users most need help interpreting. MartinLoop is open source: https://github.com/Keesan12/martin-loop. We welcome hard feedback at support@martinloop.com.