E2B Desktop Sandbox: a cloud VM with a screen for computer-use agents
E2B Desktop Sandbox for LLMs. E2B Sandbox with desktop graphical environment that you can connect to any LLM for secure computer use.
At a glance
- What is it?
- E2B Desktop Sandbox packages a graphical Linux environment behind a Python or JavaScript SDK so an LLM can click, type and scroll inside an isolated VM. It is a good fit for agent prototyping and a poor fit for anything that needs many parallel screen streams.
- Who is it for?
- Adopt E2B Desktop Sandbox if you are building a computer-use agent in Python or JavaScript and want mouse, keyboard and screen streaming handled by an SDK instead of a hand-rolled VNC stack.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What E2B Desktop Sandbox actually provides
The project gives an LLM an operating system with a display. According to the README, each sandbox is isolated from the others and can be customized with any dependencies you want. The SDK exposes that machine as an object: you create it, launch applications inside it, and drive it with mouse and keyboard calls. The repository itself is the sandbox template plus examples; the README states that the @e2b/desktop and e2b-desktop SDK sources now live in the E2B monorepo under packages/desktop-js and packages/desktop-python, and that this repository keeps the sandbox template and the examples. That split matters for anyone filing an SDK bug: open SDK issues and pull requests in the monorepo, not here. The intended audience is narrow and identifiable. If you are writing an agent that has to operate a GUI (a browser, an editor, a desktop app) rather than call an API, this removes the work of provisioning a virtual display, wiring input events, and exposing a viewable screen. If your agent only calls HTTP endpoints, a desktop VM is overhead you do not need.
The mechanism: a sandbox object, a stream, and input primitives
The data flow in the README is linear. Sandbox.create() returns a desktop handle. You call desktop.launch('google-chrome') and then desktop.wait(10000), which the example uses to give the application ten seconds to open. Screen output is delivered through a separate stream object: desktop.stream.start() begins streaming, desktop.stream.get_url() returns a URL you can open in a browser, and desktop.stream.stop() ends it. Input goes the other way through methods on the desktop object: left_click, right_click, middle_click, double_click, scroll, move_mouse, drag, mouse_press and mouse_release. Coordinates are optional; left_click() clicks wherever the pointer is, left_click(x=100, y=200) clicks a position. Streaming can be scoped to a window rather than the whole desktop. desktop.get_current_window_id() returns the active window, and desktop.get_application_windows("Firefox") returns all windows belonging to an application, which you then pass to stream.start(window_id=...). The README documents a hard constraint on this: the stream will close once the application closes, and will raise an error if the desired application is not open yet. Authentication is a flag on start: require_auth=True generates a key, retrieved with desktop.stream.get_auth_key(), and the URL is then built with desktop.stream.get_url(auth_key=auth_key). There is also a view_only option on get_url that disables user interaction.
Getting a sandbox running: API key, install, first script
The setup path is short. Sign up at E2B, take an API key, and set the environment variable E2B_API_KEY. Install with pip install e2b-desktop for Python or npm install @e2b/desktop for JavaScript. A minimal Python session, following the README example, is: import Sandbox from e2b_desktop, call desktop = Sandbox.create(), then desktop.launch('google-chrome'), then desktop.wait(10000). To watch it, call desktop.stream.start(window_id=desktop.get_current_window_id(), require_auth=True), read the key with desktop.stream.get_auth_key(), and print desktop.stream.get_url(auth_key=auth_key). The README comments out desktop.kill() at the end, which is worth noticing: the example leaves the sandbox alive unless you uncomment that line. The JavaScript version mirrors each call with camelCase names (Sandbox.create, desktop.launch, desktop.wait, stream.start, getCurrentWindowId, getAuthKey, getUrl) and awaits them. A subtle difference in the docs: the JavaScript streaming-with-password example awaits getAuthKey, while the Python one calls get_auth_key directly. Treat the SDK signatures as the source of truth and check the monorepo if a call does not match the README snippet.
The single-stream limit is the design constraint to plan around
The README is explicit in a warning block: creating multiple streams at the same time is not supported, and you may have to stop the current stream and start a new one for each application. The basic example repeats this in a comment, noting that there can be only one stream at a time and that you need to stop the current stream before streaming another application. This is the limitation most likely to bite. An agent that wants to show a user two applications side by side, or that wants to keep a monitoring view open while it drives a second window, cannot do it through this API as documented. The workaround is sequential: stop, then start against a different window_id. That serialization also shapes failure modes. Because a window-scoped stream raises an error if the application is not open yet, an agent that launches an app and immediately starts a stream without the wait step can fail; the README example uses desktop.wait(10000) for exactly this reason. And because the stream closes when the application closes, a crash in the target app ends the visual feed, which an agent loop has to detect and recover from rather than assume a stable screen.
What it is not: a general remote desktop or a browser automation library
Two comparisons are worth drawing. Against a plain E2B Sandbox without the desktop template, the difference is the graphical environment itself: the README states the desktop sandbox is built on top of E2B Sandbox, so the underlying isolation and lifecycle model are inherited, and what this project adds is the display, the application launcher, the input methods and the stream. If your task is shell commands and file edits, the base sandbox is the smaller tool. Against browser automation frameworks such as Playwright or Selenium, the approach differs at the level of control. Those tools address the DOM: you select an element and act on it. E2B Desktop Sandbox addresses pixels and coordinates: move_mouse(100, 200), then left_click(). That makes it application-agnostic (the README lists google-chrome, vscode and firefox as launch targets, and the API does not care what is on screen) but it also means the agent must locate targets visually, and there is no built-in element selector or wait-for-element primitive in the documented surface. If your target is a web page and you can script the DOM, DOM-level automation is more precise. The desktop sandbox earns its place when the target is a real application window, or when you want a human to be able to watch and take over through the stream URL.
Maintenance, versions and the licence
The repository is active, not archived, with a last push in September 2026. Releases are split by package: @e2b/desktop-python@2.4.2 in July 2026, @e2b/desktop@2.3.1 and @e2b/desktop-python@2.4.1 in June 2026. The Python and JavaScript SDKs version independently, so a snippet copied from the README can drift from the installed package; pin your version and read the release notes for the package you actually install. The licence is Apache-2.0, which permits commercial use and modification and requires that you retain the licence and notice files and state significant changes; it also includes an explicit patent grant. That is a summary of the licence text, not legal advice, and if you are redistributing the sandbox template inside a product you should have counsel read the NOTICE requirements. The larger maintenance consideration is structural: because the SDK sources moved to the E2B monorepo, this repository is now the template and examples. Bug reports about SDK behaviour belong upstream, and a fix you need may land in a package release rather than in this repository's history.
Who should adopt it, and what to check first
Adopt it if you are building a computer-use agent and want the display, input and streaming handled for you. The Python and JavaScript examples in the repository are the fastest way to see whether the model you are using can drive a GUI at all, and the streaming-apps examples show how to put that screen in front of a person. Skip it if your agent never needs a screen, if you need concurrent streams, or if you need to read and patch the SDK source in the same checkout as the template, since that source now lives under packages/desktop-python and packages/desktop-js in the E2B monorepo. Before you build on it, do three concrete checks. Confirm E2B_API_KEY is set in the environment where the sandbox is created. Confirm that the application you intend to drive is launchable by name and that a desktop.wait() interval is enough for it to appear before you start a window-scoped stream. And confirm your agent loop has a path for the case the README warns about, where the stream closes with the application or raises because the window is not open yet. Those three checks cover the failure modes the documentation actually names.
Editorial conclusion
Adopt E2B Desktop Sandbox if you are building a computer-use agent in Python or JavaScript and want mouse, keyboard and screen streaming handled by an SDK instead of a hand-rolled VNC stack. Do not adopt it if your workload needs several screen streams at once, since the README states that creating multiple streams simultaneously is not supported, or if you need the SDK source inside this repository, because it now lives in the E2B monorepo under packages/desktop-python and packages/desktop-js. Before committing, verify two things: that your E2B_API_KEY is set and the sandbox you create can launch the application you need, and that your agent loop tolerates the stream being tied to a single window that closes with the application.
Community notes