Add exec-sandbox as a CodeActAgent code executor (self-hosted QEMU microVMs)

Summary

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

Related: #14049 (user question about sandboxed code execution)

Why

• Sandboxed — The default SimpleCodeExecutor example uses bare exec(), which is unsafe. exec-sandbox runs code in isolated VMs. Fills the gap discussed in #14049.
• Self-hosted — AzureCodeInterpreterToolSpec requires Azure, AgentCoreCodeInterpreterToolSpec requires AWS. exec-sandbox runs on bare metal with just QEMU. Data never leaves the machine.
• macOS + Linux — HVF on macOS, KVM on Linux. No Docker dependency.
• Fast — ~1-2ms from warm pool, ~200ms from memory snapshots.
• Apache-2.0

How it maps

exec-sandbox is a Python library with an async API. CodeActAgent accepts any code_execute_fn: Callable | Awaitable:

from exec_sandbox import Scheduler

async with Scheduler() as scheduler:
    session = await scheduler.session(language="python")

    async def exec_sandbox_execute(code: str) -> str:
        result = await session.exec(code)
        if result.exit_code != 0:
            return f"Error:\n{result.stderr}"
        return result.stdout or "Code executed successfully (no output)"

    agent = CodeActAgent(
        code_execute_fn=exec_sandbox_execute,
        llm=llm,
        tools=[...],
    )

Could also ship as a llama-index-tools-exec-sandbox integration package with a helper class managing the lifecycle.

Open questions

• Lifecycle management — The sketch calls scheduler.__aenter__() directly. In practice, the Scheduler needs proper cleanup (__aexit__). Should the integration manage this per-agent, or use a singleton Scheduler?
• Packaging — Standalone llama-index-tools-exec-sandbox package vs contributed example?

Links

• Repo · PyPI
• Related issue: #14049

Happy to submit a PR if there's interest.