A persistent shared workspace for ephemeral agent sandboxes.

This example shows two ephemeral E2B sandboxes handing off work through a shared drive9 FUSE workspace. Sandbox A clones a repo and writes an LLM-generated code summary; Sandbox A is destroyed; Sandbox B mounts the same drive9 remote, reads the summary, and answers a question about it — all without direct sandbox-to-sandbox communication.

   ┌──────────────────────────────┐         ┌──────────────────────────────┐
   │  Sandbox A (E2B Cloud VM)    │         │  Sandbox B (E2B Cloud VM)    │
   │                              │         │                              │
   │  1. git clone <repo>         │         │  4. read code-summary.md     │
   │  2. LLM → code-summary.md    │         │  5. LLM → qa-response.md     │
   │  3. write handoff.json       │         │     (answers a question      │
   │                              │         │      about the summary)      │
   │  /home/user/workspace        │         │  /home/user/workspace        │
   │     ▲ drive9 FUSE mount      │         │     ▲ drive9 FUSE mount      │
   └─────┼────────────────────────┘         └─────┼────────────────────────┘
         │                                        │
         │      (Sandbox A is destroyed           │
         │       BEFORE Sandbox B starts)         │
         │                                        │
         └──────────────┐         ┌───────────────┘
                        ▼         ▼
              ┌──────────────────────────────┐
              │  drive9 server               │
              │  persistent shared filesystem │
              │                              │
              │  demo/<run-id>/              │
              │    project/e2b-demo/  (repo) │
              │    analysis/                 │
              │      code-summary.md         │
              │      handoff.json            │
              │      qa-response.md          │
              └──────────────────────────────┘

E2B provides ephemeral compute. drive9 provides the persistent, shared filesystem. The two sandboxes never run at the same time and never talk to each other directly — every byte of state crosses sandbox lifetimes through drive9.

Multi-agent / multi-step LLM workflows usually need somewhere to keep work between steps. Common choices each have a real cost:

• Keep the same VM alive — pay for idle compute, lose isolation between steps, can't fan out across machines.
• Stuff state into a database or object store — every artifact needs a bespoke read/write path; tools that expect a POSIX filesystem (git, grep, cat, language toolchains) don't work directly.
• Rsync / scp between sandboxes — requires both ends to be online at the same time and reachable, which defeats ephemeral compute.

drive9 offers a fourth option: mount the same remote directory as a real filesystem in each sandbox. Sandbox A can git clone into it, Sandbox B can cat from it, and in between the source VM can be destroyed. The agents share a workspace the same way two engineers share a network drive — except the "engineers" are short-lived cloud VMs that may never overlap in time.

1. Sandbox A boots and mounts the drive9 remote at /home/user/workspace via FUSE.
2. git clone runs directly into the FUSE mount, so the repo lands on drive9, not on the sandbox's local disk.
3. An OpenAI-compatible LLM reads five source files, writes analysis/code-summary.md (a structured 4-section summary) and analysis/handoff.json (metadata describing what was produced).
4. Sandbox A is unmounted and destroyed. Its local disk is gone.
5. Sandbox B boots fresh and mounts the same drive9 remote — it does not clone the repo, and it has no network channel to Sandbox A.
6. It reads handoff.json + code-summary.md from drive9, asks the LLM a question about them, and writes analysis/qa-response.md back to drive9.
7. Sandbox B is destroyed. All artifacts (cloned repo, summary, handoff, answer) remain on drive9 for inspection or for a later run.

• Node.js 20+
• E2B API key
• drive9 API key
• LLM API key for any OpenAI-compatible /chat/completions endpoint

cp .env.example .env
# Fill in E2B_API_KEY, DRIVE9_API_KEY, LLM_API_KEY

npm install
npm run build   # build the E2B sandbox template (first run)
npm run demo

Smoke test (mount + read/write round-trip, no LLM):

npm run test

MIT