home / skills / a5c-ai / babysitter / plugin-sandbox-setup

plugin-sandbox-setup skill

safe

/plugins/babysitter/skills/babysit/process/specializations/cli-mcp-development/skills/plugin-sandbox-setup

This skill helps secure plugin execution by sandboxing code with vm2 and isolated-vm patterns for reliable isolation and safe testing.

npx playbooks add skill a5c-ai/babysitter --skill plugin-sandbox-setup

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

916 B

---
name: plugin-sandbox-setup
description: Configure plugin sandboxing with vm2 or isolated-vm for secure plugin execution.
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
---

# Plugin Sandbox Setup

Configure plugin sandboxing for security.

## Generated Patterns

```typescript
import ivm from 'isolated-vm';

export async function runInSandbox(code: string, context: Record<string, unknown>) {
  const isolate = new ivm.Isolate({ memoryLimit: 128 });
  const vmContext = isolate.createContextSync();
  const jail = vmContext.global;

  for (const [key, value] of Object.entries(context)) {
    jail.setSync(key, new ivm.ExternalCopy(value).copyInto());
  }

  const script = isolate.compileScriptSync(code);
  const result = await script.run(vmContext, { timeout: 5000 });
  isolate.dispose();
  return result;
}
```

## Target Processes

- plugin-architecture-implementation
- mcp-server-security-hardening

Overview

This skill configures secure plugin sandboxing using vm2 or isolated-vm to run untrusted plugin code safely. It provides patterns and configuration options to limit memory, CPU time, and exposure to host resources. The focus is deterministic, resumable execution suitable for orchestrated agent workflows.

How this skill works

The skill sets up a separate execution isolate for each plugin, mapping only an explicit allowlist of values and functions into the sandbox. It compiles and runs plugin code inside the isolate with configurable memory and timeout limits, and disposes the isolate after execution. The configuration supports isolated-vm for low-level isolation and vm2 for a higher-level drop-in sandbox, enabling secure plugin lifecycles within Babysitter orchestration.

When to use it

Running third-party or user-provided plugins in production
Isolating plugin faults from the main agent process
Enforcing resource limits for deterministic orchestration
Hardening an MCP server or plugin architecture component
Implementing resumable or repeatable plugin runs in pipelines

Best practices

Whitelist the minimal API surface and data passed into the sandbox
Set strict memoryLimit and execution timeouts per plugin run
Avoid exposing filesystem or network primitives unless absolutely required
Serialize only primitive data and use ExternalCopy (isolated-vm) or safe clones
Dispose isolates promptly to avoid memory leaks and orphaned resources
Test sandboxed code with adversarial inputs and failure modes

Example use cases

Execute community-contributed plugins without risking host compromise
Run user automation scripts with per-run time and memory caps
Integrate sandboxed plugin runs into deterministic Babysitter workflows
Harden microservice components that load dynamic scripts on the MCP server
Provide a plugin execution endpoint that returns resumable results and sanitized outputs

FAQ

Which library should I choose: vm2 or isolated-vm?

Choose isolated-vm for strict memory isolation and efficient ExternalCopy semantics; choose vm2 for simpler context emulation and faster onboarding. Match the library to performance and API-exposure needs.

How do I avoid memory leaks when running many plugins?

Dispose isolates after use, reuse isolate pools with careful lifecycle management, and enforce memoryLimit per isolate. Monitor process memory and implement backpressure or worker recycling.