This integration uses Letta’s legacy Docker server, which is no longer actively maintained. Letta is deprecating the V1 SDK in favor of the Agent SDK and App Server, which are recommended for new projects. Use this guide to connect E2B to an existing V1 Docker deployment.
Prerequisites
- Docker
- A Letta model provider key
- An E2B API key
- Optional: an E2B sandbox template ID. Without one, Letta uses the default E2B sandbox.
Enable E2B tool sandboxing
Create a.env file for the Letta container. Do not commit this file:
E2B_API_KEY is present, Letta runs custom tools created from source code in a sandboxed environment. Set E2B_SANDBOX_TEMPLATE_ID to run those tools in your own template instead of the default E2B sandbox. The LETTA_SERVER_PASSWORD value is used to authenticate requests to the local server.
Load the same values into the shell where you run the client and curl examples:
Create and attach a custom tool
Install the Letta Python client:TOOL_ID and AGENT_ID to the IDs printed by the script, then attach the tool:
Tool lifecycle
The legacy Letta integration creates a fresh E2B sandbox for each tool call and terminates it after the call completes, including failed calls. Files, installed packages, and other runtime state do not persist between calls. Put reusable dependencies in a custom E2B template instead.E2B tool sandboxing applies to custom server-side tools created from source code. MCP tools execute on their MCP server, and built-in tools such as
memory_insert are not moved into E2B by these variables. Use client-side tools when code must run in the application that calls Letta.Security considerations
- Keep
E2B_API_KEY, model provider keys, andLETTA_SERVER_PASSWORDin a secret store or an untracked.envfile. - Treat tool arguments and tool output as untrusted because they may be influenced by an agent or user.
- If you use a custom E2B template, give it only the packages and permissions the tool needs.
- Protect the Letta server with
SECURE=truebefore exposing it beyond localhost.