E2B Sandbox

Spin up and manage E2B cloud sandboxes for agent work. Use when an OpenClaw agent needs an isolated remote Linux sandbox instead of the local workspace: crea...

Security Scan

The skill appears to implement the advertised E2B sandbox management features, but there are multiple coherence and scope issues (missing declared requirements, filesystem writes, and env handling) that you should review before installing or using it.

Purpose & Capability

The code implements the stated purpose (creating/listing/executing/hosting/snapshotting/killing E2B sandboxes using the e2b SDK). However the registry metadata is inconsistent: SKILL.md and the scripts require E2B_API_KEY and a Node runtime, yet the registry entry lists no required env vars or required binaries. The package includes dependencies (@modelcontextprotocol/sdk and e2b) which are expected for this purpose.

Instruction Scope

Runtime instructions and scripts will read/write user files in home (~/.openclaw/workspace/config/mcporter.json and ~/.openclaw/workspace/.state/e2b-sandboxes.json) and launch a local MCP server. The SKILL.md and register script instruct adding an MCP server entry and the code will create and update a state file. The fallback wrapper may run npm install automatically when first invoked. These file writes and possible automated installs are outside a purely 'read-only' helper and should be expected and reviewed.

Install Mechanism

There is no formal install spec, but scripts include a run-e2b.sh that will run `npm install` in the skill directory if node_modules are missing. Dependencies come from the public npm registry (package-lock.json visible). This is a moderate risk vector (remote packages executed locally) but is expected for a Node-based skill; it should be audited before running.

Credentials

The skill requires an E2B_API_KEY (enforced in multiple scripts), but the registry metadata did not declare it as a required environment variable or primary credential — an important mismatch. The scripts also accept and forward env key/value pairs into created sandboxes (create/exec with envs), which could unintentionally transmit local secrets into a remote environment if the agent or user supplies them. The register script writes a config entry with the placeholder '${E2B_API_KEY}' (it does not inject your secret for you), so you must provide the real key in the environment or Vault. Overall the credential request is coherent for sandbox control, but the risk of leaking other env vars into remote sandboxes is real and must be considered.

Persistence & Privilege

The skill is not marked always:true and does not autonomously escalate platform-wide privileges. It does, however, persist configuration by writing an MCP server entry to ~/.openclaw/workspace/config/mcporter.json and tracking sandboxes in ~/.openclaw/workspace/.state/e2b-sandboxes.json. Registering the MCP server makes the skill's local server available to agents via mcporter; that persistent registration is expected for this functionality but is a persistent side-effect you should approve.

What to consider before installing

This skill appears to actually implement E2B sandbox management, but there are a few things to check before installing/using it: - The skill requires E2B_API_KEY and a Node runtime, but the registry metadata omitted those declarations — assume you must provide E2B_API_KEY in your environment or Vault and ensure node is available. - The register script will write an MCP server entry to ~/.openclaw/workspace/config/mcporter.json and the skill will store sandbox state in ~/.openclaw/workspace/.state/e2b-sandboxes.json. If you don't want these files created/modified, don't run the register helper. - The fallback wrapper (run-e2b.sh) can run npm install in the skill directory on first use; review package-lock.json and the dependencies (notably the public 'e2b' SDK and @modelcontextprotocol/sdk) before allowing the install. - Be careful about forwarding environment variables into created sandboxes (the scripts accept envs). Do NOT pass secrets (AWS keys, tokens, etc.) into sandbox envs unless you trust the remote provider and sandbox network exposure — remote sandboxes can expose services and could leak data. - Confirm you trust the skill author and the e2b provider (the skill will create externally reachable URLs for exposed ports). If in doubt, inspect scripts/e2b-core.mjs and e2b-mcp-server.mjs locally and consider running them in an isolated environment where you control the E2B_API_KEY and network exposure. If you want to proceed: set a minimal-scoped E2B API key, run the scripts manually after review (don't blindly run register), and avoid passing sensitive local environment variables into sandboxes.

Use this skill when the task should run in an E2B sandbox rather than directly on the OpenClaw host.

Credentials

This skill requires E2B_API_KEY in the environment. Configure it in Vault / env before use.

MCPorter-native setup

Register the local MCP server once:

node /home/charl/.openclaw/workspace/skills/e2b-sandbox/scripts/register-mcporter.mjs

This writes an e2b-sandbox entry into:

~/.openclaw/workspace/config/mcporter.json

Then verify it:

mcporter list e2b-sandbox --schema

Primary usage

After registration, prefer MCP tools instead of shell wrappers.

Expected tool names:

• e2b-sandbox.create_sandbox
• e2b-sandbox.list_sandboxes
• e2b-sandbox.get_info
• e2b-sandbox.exec
• e2b-sandbox.host
• e2b-sandbox.set_timeout
• e2b-sandbox.snapshot
• e2b-sandbox.kill

Example low-level calls:

mcporter call e2b-sandbox.create_sandbox --args '{"label":"codex-lab","template":"base","timeoutMs":3600000}'
mcporter call e2b-sandbox.exec --args '{"sandbox":"codex-lab","cmd":"python3 --version"}'
mcporter call e2b-sandbox.host --args '{"sandbox":"codex-lab","port":3000}'

Shell helper fallback

A wrapper still exists for debugging or environments where you want direct script access:

/home/charl/.openclaw/workspace/skills/e2b-sandbox/scripts/run-e2b.sh help

Notes

• Sandbox ids and labels are tracked in ~/.openclaw/workspace/.state/e2b-sandboxes.json.
• Prefer labels for longer tasks so later steps can refer to the same sandbox cleanly.
• The MCP server is local and uses the E2B Node SDK under the hood.
• Use this helper for one-shot command execution. If a task needs a long interactive PTY session or a specialized template flow, read references/e2b-notes.md first.
• If a task needs a custom image or preinstalled stack, create the sandbox/template first, then snapshot it for reuse.

Read next when needed

Read references/e2b-notes.md when you need:

• state-file behavior
• timeout / snapshot guidance
• port exposure reminders
• when to use MCP tools vs the shell helper