make-e2b-code-execution

E2B コード実行の作成

ユーザーがコードを永続的なツールにしたい場合に、このスキルを使用します。

既知の E2B モジュール ID：E2B サンドボックスモジュールは "module": "e2b:RunE2BSandbox"、"version": 0 です。

アーキテクチャは次のとおりです。

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

そのコードで SaaS データが必要な場合は、 make-api-shell-connection-workflow の Make API シェルシナリオを呼び出す必要があります。生成するコードに OAuth シークレット、Make API トークン、 E2B API キー、リフレッシュトークン、プロバイダーのパスワード、またはプロバイダー SDK の直接認証情報を含めないでください。

保存ルール

永続的なコード成果物は、設定済みの Hermes Code フォルダー以下に保存します。

• ローカルナレッジストア：knowledge/hermes/Code/...
• Google Drive ナレッジストア：/Hermes/Code/...

以下のようなランタイムヘルパーを使用します。

import make_api_shell as make

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

ユーザーが一時的なローカル作業ファイルを明示的に求めた場合を除き、シェルのリダイレクト、open(...)、Path.write_text(...) を使って永続的なコードファイルを直接書き込まないでください。

実行モード

通常のコード実行

ホストされない短時間のコードには、次の方法を使用します。

1. コード成果物を Code/ 以下に書き込みます。
2. ローカルの code_execution ツールで実行します。
3. 短い実行メモまたは出力成果物は、設定済みの Knowledge ヘルパーを通じてのみ書き込みます。

ホスト型 E2B コードシェル

コードを再利用可能なホスト型ツールにする場合は、次の方法を使用します。

1. コード成果物を Code/ 以下に書き込みます。
2. E2B コードシェルの契約に合った Make シナリオを作成するか、既存のものを再利用します。
3. codePath、language、entrypoint、input、mode、timeoutMs を指定してシェルを実行します。
4. E2B シェルの出力をツールの結果として扱います。

Make シナリオはコントロールプレーンのシェルです。E2B はランタイムにすぎません。エージェントが E2B の認証情報を受け取ることはありません。

検証済みの e2b Make アプリでシェルを構築する（ライブ検証済み）

インフラストラクチャランナーの URL を利用できない場合は、Make で検証済みのアプリ e2b（「e2b.dev」、ベータ版、メジャーバージョン 0）のアプリアクションシェルとして、モジュール e2b:RunE2BSandbox を使って E2B コードシェルを構築します。

• モジュールのマッパーフィールド：execLanguage（python／javascript）、inputFormat （string／base64）、dependencies（配列）、timeoutSeconds（数値、 必須）、code（テキスト、必須）。標準シェルインターフェースから入力を {{2.qs.<field>}} としてマッピングします。
• 接続は e2b／RunE2BSandbox の認証情報リクエストから取得します。次の 2 か所にバインドしてください。シェル検証で必要となるレガシーの __IMTCONN__ と、モジュールで宣言されたパラメーター account です。manifest-2／SDK モジュールは __IMTCONN__ を無視するため、そうしないと認証情報なしで実行されます。ヘルパー環境では、create_app_action_shell_scenario に connection_parameter="account" を渡します。
• 初回実行の前に、シナリオのインターフェースを汎用シェル契約に合わせて修正し、その後シナリオを有効化します。
• モジュールの出力フィールドは logs で、形式は {"stdout": ["..."], "stderr": []} です。ReturnData は {"data": "{{<moduleId>.logs}}"} としてマッピングします（stdout／result／output は存在せず、何も返されずに null になります）。ヘルパー環境では return_field="logs" を使用します。
• Make UI でシナリオを編集すると、モジュール ID が振り直され、モジュールのパラメーターも書き換えられます（__IMTCONN__ が削除されます）。UI で編集した後は必ずブループリントを再読み込みし、接続を両方に再バインドして、ReturnData の参照先を新しいモジュール ID に修正してください。古い参照のままでは、それ以外は成功した実行でも data: null が返されます。
• モジュールの E2B エラーの特徴：401: authorization header is missing は、モジュールからキーが送信されていないこと（接続がバインドされていないこと）を示します。 401: authorization header is malformed は、保存された apiKey が e2b_ で始まっていないことを示します。よくある原因は、「Bearer 」のプレフィックス、引用符、API Key の代わりに貼り付けた sk_e2b_... Access Token、または保存時に UI で変更が暗黙に保存されなかったことです（POST /connections/{id}/set-data で修正してください）。e2b アプリは X-API-Key: <apiKey> をそのまま送信するため、e2b_... のキー本体を保存します。

ネストされた SaaS へのアクセス

「インセプション」ツールの場合、生成されたコードから Make API シェルシナリオを呼び出すことができます。

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

ホストされたコードに渡すのは、シナリオ ID、パス、リクエストペイロード、機密情報ではない入力データだけにしてください。Make またはプロバイダーの認証情報をそのまま渡してはいけません。

参考資料

• 実行モード
• E2B Code Shell シナリオの仕様