Proposal: BoxLite MCP server for hardware-isolated sandboxed code execution

Proposal: BoxLite MCP server for hardware-isolated sandboxed code execution

Hi Codex team! 👋

First off, fantastic work on Codex CLI—having a local coding agent with MCP support and execution policies is a powerful approach to safe automation. The Model Context Protocol integration is particularly well-designed for extensibility.

I've been working on BoxLite (github.com/boxlite-labs/boxlite), an embeddable VM runtime, and I think there's a natural integration opportunity via MCP that could enhance Codex's sandboxing with hardware-level isolation—especially for code execution, testing workflows, and GitHub Actions.

---

Current State & Opportunity

Codex currently provides:

• ✅ Execution policies - Configurable rules for command execution
• ✅ Sandbox mode - Approval workflows for safety
• ✅ MCP support - Extensibility via Model Context Protocol
• ✅ Interactive & non-interactive - Flexible usage modes
• ✅ GitHub Actions integration - CI/CD automation

While the existing sandbox mode with approval workflows is excellent for controlling what gets executed, there are scenarios where hardware-level isolation could provide additional value:

• Testing untrusted code - Execute code suggestions in true VMs, not just with approval
• Reproducible environments - Same Linux environment across all team members
• GitHub Actions isolation - Clean, isolated CI/CD runs
• Safe experimentation - Try risky operations without host contamination
• Team consistency - Eliminate "works on my machine" issues

---

What is BoxLite?

BoxLite (github.com/boxlite-labs/boxlite) takes an "embeddable library" approach to sandboxing—think SQLite for VMs. Instead of requiring Docker Desktop or a daemon, it's a library that provides hardware-level isolated environments.

Core characteristics:

• Hardware virtualization (KVM/Hypervisor.framework) — Real VMs, not just process isolation
• No daemon dependency — Just a Python library (pip install boxlite)
• OCI-compatible — Uses standard Docker images from any registry
• Cross-platform — macOS (Apple Silicon) and Linux (x86_64, ARM64)
• Embeddable — No root required, works in serverless environments

Architecture:

Codex CLI
└── MCP Server (BoxLite)
    └── Micro-VMs (hardware virtualized)
        └── OCI Containers (Linux environments)

---

Integration via MCP (Model Context Protocol)

Since Codex already supports MCP servers, BoxLite can integrate as an MCP server without any changes to Codex core. This makes it a natural, opt-in extension.

Configuration

Users would configure BoxLite in ~/.codex/config.toml:

[[mcp.servers.boxlite]]
command = "boxlite-mcp-server"
args = []
env = {}

[mcp.servers.boxlite.config]
default_image = "python:3.11-slim"
cpu = 2
memory = 2048

MCP Server Tools

The BoxLite MCP server would expose these tools to Codex:

{
  "tools": [
    {
      "name": "execute_code",
      "description": "Execute code in an isolated VM",
      "parameters": {
        "code": "string",
        "language": "python|node|rust|...",
        "test_command": "optional test to run"
      }
    },
    {
      "name": "run_command",
      "description": "Run shell command in isolated environment",
      "parameters": {
        "command": "string",
        "working_dir": "string"
      }
    },
    {
      "name": "create_environment",
      "description": "Create a persistent isolated environment",
      "parameters": {
        "image": "OCI image name",
        "volumes": "optional host mounts"
      }
    }
  ]
}

---

Use Cases

1. Safe Code Execution 🛡️

Current flow:

Codex suggests code → User approves → Execute locally

With BoxLite MCP:

Codex suggests code → Execute in BoxLite VM → Run tests → Apply if successful

2. Reproducible Testing ✅

Challenge: Tests pass locally but fail in CI due to environment differences

With BoxLite MCP:

# Same environment locally and in GitHub Actions
codex exec --mcp-server=boxlite "run full test suite"

# Guaranteed same Linux environment every time
# No accumulated state or local configuration interference

3. GitHub Actions Enhancement 🚀

Use BoxLite for isolated execution in CI/CD:

# .github/workflows/codex.yml
- name: Run Codex with BoxLite isolation
  run: codex exec --mcp-server=boxlite "run tests and build"

Benefits:

• Clean environment for each run
• No Docker-in-Docker complexity
• Consistent with local development

4. Safe Experimentation 🧪

Try risky operations without fear:

# Large refactoring with automatic rollback
codex "refactor entire authentication system"
# → Executes in BoxLite VM
# → Tests automatically
# → Only applies if tests pass in isolation

5. Team Consistency 👥

Same environment across all developers:

• Junior developer on macOS
• Senior developer on Linux
• CI/CD in GitHub Actions
• All use identical Linux environment via BoxLite

---

Code Example: BoxLite MCP Server

Here's how the BoxLite MCP server would work (simplified):

import boxlite
from mcp import Server, Tool

server = Server("boxlite")

@server.tool()
async def execute_code(code: str, language: str = "python") -> dict:
    """Execute code in isolated VM"""
    async with boxlite.CodeBox(image=f"{language}:latest") as sandbox:
        # Execute code
        result = await sandbox.run(code)

        # Run tests if specified
        test_result = await sandbox.exec("pytest", "-v")

        return {
            "stdout": result.stdout,
            "stderr": result.stderr,
            "exit_code": result.exit_code,
            "tests_passed": test_result.exit_code == 0
        }

@server.tool()
async def run_command(command: str, working_dir: str = "/workspace") -> dict:
    """Run command in isolated environment"""
    async with boxlite.SimpleBox(image="ubuntu:latest") as box:
        result = await box.exec("bash", "-c", command, cwd=working_dir)
        return {
            "stdout": result.stdout,
            "stderr": result.stderr,
            "exit_code": result.exit_code
        }

if __name__ == "__main__":
    server.run()

---

Potential Benefits for Codex Users

1. Enhanced Security

• Hardware-level isolation - VMs, not just approval workflows
• Prevent host contamination - Nothing escapes the VM
• Safe untrusted code execution - Test before applying

2. Reproducibility

• Same environment everywhere - macOS, Linux, CI/CD
• No "works on my machine" - Consistent across team
• OCI images - Use standard Docker images

3. Developer Experience

• No Docker Desktop - Works without daemon on macOS
• Fast startup - Micro-VMs in ~100-500ms
• MCP native - Uses Codex's existing extension system

4. CI/CD Benefits

• Clean GitHub Actions - Isolated, reproducible builds
• No Docker-in-Docker - BoxLite doesn't need Docker
• Consistent local/CI - Same environment everywhere

5. Flexibility

• Opt-in - Users choose when to use BoxLite MCP
• Configurable - Image, resources, volumes customizable
• Works with existing - Doesn't replace current sandbox mode

---

Trade-offs & Considerations

When Current Sandbox Mode is Better

• ✅ Simple commands - Git status, file reads, quick edits
• ✅ Trusted operations - Well-known, vetted code
• ✅ Speed-critical - Local execution is always faster
• ✅ Interactive prompts - Approval workflow for control

When BoxLite MCP Helps

• ✅ Code execution - Testing Codex suggestions before applying
• ✅ Untrusted code - Unknown or risky operations
• ✅ Build/test commands - Reproducible, clean environments
• ✅ GitHub Actions - Isolated CI/CD runs
• ✅ Team environments - Consistent behavior across developers

Recommendation: Make it optional via MCP configuration. Users opt-in when they need hardware isolation.

---

BoxLite Status

• Current version: 0.4.4 on PyPI
• License: Apache 2.0 (same as Codex)
• Platforms: macOS (Apple Silicon), Linux (x86_64, ARM64)
• GitHub: https://github.com/boxlite-labs/boxlite
• Python SDK: Stable, asyncio-native
• MCP Server: Would need to be built (can provide POC)
• Production readiness: Early stage, used in production by some teams

---

Potential Next Steps

If this seems interesting, I'd be happy to:

1. Build a BoxLite MCP server - Create working prototype for Codex
2. Provide benchmarks - Show overhead vs isolation trade-offs
3. Create example configurations - Document setup and usage
4. Collaborate on integration - Work with your team on implementation

No pressure—mainly wanted to share this since Codex already has MCP support and BoxLite could provide hardware-isolated sandboxing as an opt-in extension.

---

Feedback Welcome

I'd love to hear your thoughts on:

• Whether hardware-isolated sandboxing aligns with Codex's vision
• What MCP server capabilities would be most valuable
• Any concerns about the MCP integration approach
• What use cases matter most to Codex users

And if you're interested in BoxLite for other projects, feel free to check it out—we're building in public and feedback helps! A ⭐ on GitHub would be appreciated if you find it useful.

---

Disclosure: I'm one of the BoxLite maintainers, but I genuinely think there's natural synergy here given Codex's MCP architecture. Looking forward to your thoughts!