Secure Compute Environment Accelerator (SCE-MCP) 🛡️

This Machine Control Protocol (MCP) service furnishes AI agents with a highly constrained, containerized runtime. By leveraging Docker technology, it guarantees process isolation, making it safe to run potentially untrusted code payloads.

Core Capabilities

• Isolation via Containers: Provision dedicated, ephemeral Docker execution contexts.
• Image Flexibility: Permits utilization of any user-specified Docker base image for the runtime.
• Data Transfer: Seamless mechanisms for uploading/downloading directories and individual files.
• Remote Command Invocation: Ability to dispatch and execute arbitrary shell sequences within the isolated guest.
• Live Telemetry: Provides bidirectional, real-time streams of container output (stdout/stderr).
• Self-Maintenance: Incorporates automated checks for software updates and binary patching.
• OS Compatibility: Functions across Linux, macOS, and Windows operating systems.

🚀 Deployment Instructions

Prerequisites

Ensure Docker Engine is installed and operational on the host system. * Docker Installation Guide (Linux) * Docker Desktop (macOS) * Docker Desktop (Windows)

Expedited Setup

Unix-Like Shells (Bash/Zsh)

bash curl -fsSL https://raw.githubusercontent.com/Automata-Labs-team/code-sandbox-mcp/main/install.sh | bash

Windows PowerShell

powershell

Execute in PowerShell terminal

irm https://raw.githubusercontent.com/Automata-Labs-team/code-sandbox-mcp/main/install.ps1 | iex

The installation script performs: 1. Verification of Docker daemon availability. 2. Acquisition of the platform-specific executable. 3. Generation of requisite configuration artifacts.

Manual Setup Procedure

1. Obtain the latest compiled release artifact corresponding to your host OS from the official releases repository.
2. Place the binary file within a directory indexed by your system's PATH environment variable.
3. Grant execution permissions (for Linux/macOS environments): bash chmod +x code-sandbox-mcp

🛠️ Available Services (Tools)

sandbox_initialize

Provisions a new, clean execution context based on the designated container blueprint.

Arguments: - image (string, default: 'python:3.12-slim-bookworm'): The underlying Docker image specification.

Output: - container_id: A unique identifier necessary for subsequent operational calls against this session.

copy_project

Transfers an entire local folder structure into the running sandbox filesystem.

Arguments: - container_id (string, mandatory): Target session identifier. - local_src_dir (string, mandatory): Absolute or relative path to the source directory locally. - dest_dir (string, optional): Target directory path inside the container.

write_file

Creates or overwrites a file within the sandboxed environment with provided content.

Arguments: - container_id (string, mandatory): Target session identifier. - file_name (string, mandatory): The desired filename. - file_contents (string, mandatory): The textual data payload for the file. - dest_dir (string, optional): The directory where the file should reside (defaults to the container's working directory).

sandbox_exec

Executes a sequence of shell commands inside the established isolation boundary.

Arguments: - container_id (string, mandatory): Target session identifier. - commands (array of strings, mandatory): The ordered list of shell instructions to execute.

copy_file

Moves a single local file into the container's file system.

Arguments: - container_id (string, mandatory): Target session identifier. - local_src_file (string, mandatory): Path to the singular source file locally. - dest_path (string, optional): Final location and name within the sandbox.

sandbox_stop

Terminates and completely purges the specified container instance and any associated storage volumes.

Arguments: - container_id (string, mandatory): The identifier of the session to decommission.

Rationale: Performs a controlled shutdown (10-second grace period) before resource reclamation.

Container Output Stream Resource

A dedicated endpoint for retrieving chronological execution logs.

Endpoint: containers://{id}/logs
Media Type: text/plain
Function: Aggregates and returns the entire accumulated log history for the specified container ID.

🔐 Security Posture

• Execution is strictly confined using Docker process separation.
• System resources (CPU, memory) are constrained via native Docker limitations.
• Standard output and standard error channels are demultiplexed for clean reporting.

🔧 Configuration Reference

Integration with Claude Desktop

The installation script automatically configures the necessary service endpoint. For manual override or inspection, consult the following paths:

Linux Path

// ~/.config/Claude/claude_desktop_config.json { "mcpServers": { "code-sandbox-mcp": { "command": "/path/to/code-sandbox-mcp", "args": [], "env": {} } } }

macOS Path

// ~/Library/Application Support/Claude/claude_desktop_config.json { "mcpServers": { "code-sandbox-mcp": { "command": "/path/to/code-sandbox-mcp", "args": [], "env": {} } } }

Windows Path

// %APPDATA%\Claude\claude_desktop_config.json { "mcpServers": { "code-sandbox-mcp": { "command": "C:\path\to\code-sandbox-mcp.exe", "args": [], "env": {} } } }

External Service Integration

Other compatible AI frameworks should point their backend execution channel toward the code-sandbox-mcp binary path for sandboxed operation.

🏗️ Development & Contribution

Details regarding local compilation, testing, and feature contribution are documented in DEVELOPMENT.md.

📝 Licensing

This software is distributed under the permissive terms of the MIT License. See the LICENSE artifact for full legal text.

WIKIPEDIA CONTEXT: Cloud Computing Fundamentals

Cloud computing, as defined by ISO, represents an architectural approach for delivering scalable, elastic IT capabilities over a network via on-demand, self-service provisioning. It is universally known as 'the cloud'.

== NIST Essential Characteristics (2011) == In 2011, the National Institute of Standards and Technology (NIST) established five fundamental qualities for a genuine cloud service model:

1. On-demand self-service: Users procure computing resources (e.g., compute cycles, storage capacity) autonomously without requiring provider human intervention.
2. Broad network access: Services must be reachable via standard protocols, supporting diverse client apparatuses (mobile, desktop, etc.).
3. Resource pooling: Provider resources are shared across multiple tenants (multi-tenancy), with dynamic allocation based on current demand.
4. Rapid elasticity: The ability to provision and de-provision capacity quickly, often automatically, to perfectly match fluctuating workload requirements.
5. Measured service: Utilization tracking implemented at an abstraction layer appropriate to the service type (e.g., processing units, data transfer), ensuring transparent reporting for both consumer and provider.

ISO subsequently enhanced and formalized this taxonomy by 2023.

== Historical Precursors ==

The conceptual foundation of cloud computing traces back to the 1960s with the widespread adoption of time-sharing systems, typically accessed via Remote Job Entry (RJE). This era centered on centralized mainframe operation managed by specialized staff. The visual representation of 'the cloud' materialized around 1994, employed by General Magic to depict the accessible sphere for their mobile agents in the Telescript framework. This graphical convention, attributed to General Magic's David Hoffman, built upon established telecommunications symbology. The term 'cloud computing' gained broader commercial traction in 1996 following internal business planning documents at Compaq Computer Corporation, outlining future internet-centric computation strategies.