Make E2b Code Execution

Make E2B Code Execution

Use this skill when the user wants code to become a durable tool.

Known E2B module id: the E2B sandbox module is "module": "e2b:RunE2BSandbox" with "version": 0.

The architecture is:

Hermes writes code -> Code folder -> local execution or Make E2B Code Shell -> E2B runtime

If that code needs SaaS data, it must call a Make API shell scenario from make-api-shell-connection-workflow. Do not put OAuth secrets, Make API tokens, E2B API keys, refresh tokens, provider passwords, or direct provider SDK auth in generated code.

Storage Rule

Store all durable code artifacts below the configured Hermes Code folder:

• local knowledge store: knowledge/hermes/Code/...
• Google Drive knowledge store: /Hermes/Code/...

Use the runtime helper, for example:

import make_api_shell as make

make.write_code_artifact(
    "tools/calc.py",
    "print(17 * 23)\\n",
    language="python",
    confirm=True,
)

Do not write durable code files directly with shell redirection, open(...), or Path.write_text(...) unless the user explicitly asked for a temporary local scratch file.

Execution Modes

Plain Code Execution

Use this for quick, non-hosted code:

1. Write the code artifact under Code/. 2. Run it with the local code_execution tool. 3. Write a short run note or output artifact only through the configured Knowledge helper.

Hosted E2B Code Shell

Use this when the code should become a reusable hosted tool:

1. Write the code artifact under Code/. 2. Create or reuse a Make scenario that matches the E2B Code Shell contract. 3. Run the shell with codePath, language, entrypoint, input, mode, and timeoutMs. 4. Treat the E2B shell output as the tool result.

The Make scenario is the control-plane shell. E2B is only the runtime. The agent never receives E2B credentials.

Building the shell on the verified e2b Make app (verified live)

When no infrastructure runner URL is available, build the E2B Code Shell as an app-action shell on the Make-verified app e2b ("e2b.dev", beta, major version 0), module e2b:RunE2BSandbox:

• Module mapper fields: execLanguage (python/javascript), inputFormat

(string/base64), dependencies (array), timeoutSeconds (number, required), code (text, required). Map inputs from the standard shell interface as {{2.qs.<field>}}.

• The connection comes from a credential request for e2b /

RunE2BSandbox. Bind it twice: as legacy __IMTCONN__ (required by the shell verifier) and as the module's declared parameter account — manifest-2/SDK modules ignore __IMTCONN__ and otherwise run without credentials. In helper environments pass connection_parameter="account" to create_app_action_shell_scenario.

• Patch the scenario interface to the generic shell contract before the first

run, then activate the scenario.

• The module's output field is `logs` with shape

{"stdout": ["..."], "stderr": []} — map ReturnData as {"data": "{{<moduleId>.logs}}"} (stdout/result/output do not exist and silently return null). Use return_field="logs" in helper environments.

• Editing the scenario in the Make UI renumbers module ids and rewrites

the module parameters (dropping __IMTCONN__). After any UI edit, re-read the blueprint, re-bind the connection both ways, and fix the ReturnData reference to the new module id — a stale reference returns data: null on otherwise successful runs.

• E2B error fingerprints from the module: `401: authorization header is

missing means the module sent no key (connection not bound); 401: authorization header is malformed means the stored apiKey does not start with e2b_ — common causes: a "Bearer " prefix, quotes, the sk_e2b_... Access Token pasted instead of the API Key, or a UI save that silently did not persist (fix via POST /connections/{id}/set-data). The e2b app sends X-API-Key: <apiKey> raw, so store the bare e2b_...` key.

Nested SaaS Access

For “inception” tools, generated code may call Make API shell scenarios:

Hosted code -> Make Gmail API shell -> Gmail API

The hosted code should receive only scenario IDs, paths, request payloads, and non-secret input data. It must never receive raw Make or provider credentials.

References

• Execution modes
• E2B Code Shell scenario contract

E2B Code Shell Scenario Contract

An E2B Code Shell is a Make on-demand scenario with this logical shape:

StartSubscenario -> HTTP request to infrastructure-owned E2B runner -> ReturnData

Inputs

The scenario interface must accept:

• codePath: path below the Hermes Code/ folder
• language: runtime language such as python, javascript, or typescript
• entrypoint: optional entry file or command
• input: JSON-compatible input object
• mode: preview or run
• timeoutMs: execution timeout

Output

Return a JSON-compatible object:

{
  "ok": true,
  "stdout": "",
  "stderr": "",
  "resultJson": {},
  "artifacts": [],
  "scenarioId": 123,
  "sandboxRunId": "run_..."
}

Security rules

• The scenario may call the E2B runner endpoint, but Hermes must not see E2B

credentials.

• Hosted code must not receive raw Make, OAuth, OpenAI, or provider secrets.
• SaaS access from hosted code must go through Make API shell scenarios.
• Writes and destructive operations require explicit confirmation.

Execution Modes

Plain code execution

Use plain execution when the user wants a calculation, transformation, one-off script, or first prototype. Persist the source under Code/, then run it with the local code execution tool.

Expected proof:

• code artifact path under Code/
• stdout/stderr or JSON result
• process-mining entry for the code run

Hosted E2B Code Shell

Use hosted execution when the code should be reusable, isolated, or callable as a tool later. Make owns the scenario. Infrastructure owns the E2B runner. Hermes provides code references and input only.

Expected proof:

• code artifact path under Code/
• Make scenario ID for the E2B shell
• E2B sandbox/run ID returned by the runner
• process-mining entries for code write, shell run, and result

SaaS calls from hosted code

Generated hosted code may call Make API shell scenarios for Gmail, Calendar, Sheets, CRM, Slack, or other SaaS systems. It must not use native provider SDK auth, browser auth, IMAP/SMTP, raw OAuth, or direct token handling.