E2B Sandbox

/dev/fuse

local ext4 disk

  shell

network client

Remote Cache

       Remote Object storage

Remote File System API

file metadata

file content

The shell program sends a series of system calls to the kernel, including <>.

Similar to a file write operation, the kernel resolves the provided path to determine where <>

kernel

RAM

Since /my/folder is on a FUSE path, the kernel sends the request to the /dev/fuse channel, where the FUSE daemon picks up the requests and executes a network request to the remote virtual file system API.

FUSE Daemon

The FUSE daemon uses the metadata to <>. It then streams the file content in small chunks into the microVM's local memory. Once the streaming is done, it leaves a completion reply in the /dev/fuse channel, which the kernel picks up. 

The kernel then wakes up the shell program that had been waiting for a reply. THe shell program then processes the file bytes and returns the string content upstream.

file metadata

 Agentic platform

  Chat interface

Agent: Okay, I am creating the file

A file read behaves similarly to a file write for the initial parts of the journey.

As before, LLM responses are split into the user-visible text responses and tool calls.

envd

The harness maps the use_computer tool call to code that sends the shell command to the sandbox via a network request.

tool call -> action

USER-VISIBLE TEXT

TOOL CALL

  

Agent: Okay, I have created hello.txt at /my/folder/hello.txt

User: Can you read the file and confirm the text that you see?

Agent: I'll read hello.txt

The file system API interprets the request and first looks up the file system metadata to determine if the file exists on its end, checks the user/agent's access permissions and determines where the corresponding raw file content is. It then returns this metadata information back to the FUSE daemon.

Agent: It says "Hello World"