Skip to main content
Mount a Supermemory container inside an E2B sandbox so your agent can read and write memory using standard filesystem commands.

How it works

There are two ways to wire SMFS into an E2B sandbox — pick the one that fits your architecture.

Agent inside the sandbox

The agent process runs inside the sandbox and accesses the SMFS mount directly. Your orchestrating code just boots the sandbox and kicks off the agent.

Agent outside the sandbox

The agent runs in your orchestrating code and executes commands inside the sandbox remotely. Useful when you want to keep the agent loop in your own infra.

Prerequisites

1. Create a custom template

Bake SMFS and the Claude Agent SDK into a template so sandboxes start ready:
e2b.Dockerfile

Pattern A: Agent inside the sandbox

The agent runs inside the sandbox as a Python script. Your orchestrating code just sets up the mount and starts it.

Agent code

agent.py

Orchestration

run.py

Pattern B: Agent outside the sandbox

The agent runs in your server process and executes commands inside the sandbox remotely via sbx.commands.run(). The SMFS mount lives inside the sandbox — the agent never touches the filesystem directly.
The FUSE mount is owned by root inside the sandbox. When writing to it from outside the agent, wrap the command in sudo bash -c '…' so the redirect runs with the right permissions. You’ll see this in the write examples below.
run.py

Tips

  • Use --ephemeral for sandbox mounts — keeps the cache in memory only, but writes still push to Supermemory
  • Use smfs grep 'query' for semantic search across all files in the container
  • Without a custom template, add the install steps to your run script: