Summary: Daytona has published a guide for connecting OpenAI’s ComputerToolset helper to a browser running on a Daytona desktop sandbox. The helper runs the screenshot-and-act loop, but the guide’s core idea is architectural: the toolset never creates or manages the sandbox, so your application writes a driver that decides exactly which actions the model may take. That split — model loop to OpenAI, desktop to Daytona, policy to you — is worth copying even if you never run this exact stack.
What the integration actually does
The example is one Python script. It creates a Daytona sandbox from a snapshot with Computer Use packages, starts the desktop, waits until get_status() reports active, launches Chromium on DISPLAY=:0, and hands the screen to OpenAI’s ComputerToolset, which ships in OpenAI Python SDK 3.31.0 and Node SDK 7.33.0. The task is deliberately small: the model opens the Python docs and reports the page heading. The toolset takes screenshots, sends them to the model, and dispatches the actions the model requests.
Setup is three environment variables — an OpenAI key, a model that supports the native computer tool, and a Daytona key — and two installs. Each run bills both OpenAI model usage and Daytona sandbox runtime, so auto_stop_interval and auto_delete_interval bound the sandbox lifetime in case the script dies before cleanup.
The driver is the safety boundary
DaytonaDriver implements the nine methods ComputerToolset requires, but only two do anything. screenshot returns a base64 PNG in the expected computer_screenshot shape. click allows exactly one plain left click, verified to land inside the display bounds. Everything else — double_click, drag, keypress, move, scroll, type, wait — aliases to an unsupported method that raises. A model that tries to type or scroll ends the run.
There’s a second gate on top. run() accepts approval callbacks: before_action only permits the two allowed action types, and approve_screenshot-style approve_safety_checks returns False, so a pending model safety check stops the run instead of being waved through. Daytona’s guidance on adapting the example is to extend the driver one method at a time with the same bounds checks — never loosen the callbacks, because a permissive driver can’t be undone by a strict prompt.
Small details that make it production-shaped
A few choices in the script are the real lessons:
store: Falsekeeps the conversation out of OpenAI’s storage, andtool_choice: "required"forces the model to actually use the computer tool rather than answer from memory.- The script raises if
driver.clickedis still false, catching a model that claims success without acting. But the guide itself notes this only proves the driver accepted a click, not where it landed — verify results independently. - Cleanup is a nested
finally: toolset close first, sandbox delete withwait=Truesecond, so deletion still runs iftoolset.close()raises. - For repeated runs, Daytona suggests pre-baking browser and page state into a snapshot, and restricting sandbox network access to the domains the task needs.
One warning deserves emphasis: screenshots are part of the model request, so treat everything visible on the desktop as shared with OpenAI. The guide’s advice — a dedicated, disposable desktop with no real accounts or credentials — pairs well with the sandbox isolation patterns covered in Codex Update: From Writing Code to Operating Your Computer.
Why this split matters
Most computer-use demos bolt permissions into the prompt. This guide puts them in code, between the model and the machine. That’s the right default for anyone shipping agents: the provider owns the loop, the sandbox vendor owns the environment, and your application stays the single place where capability is granted or denied. The honest limitation is that it’s still trust-but-verify — the driver can enforce what was clicked, not whether it was the right thing, so keep a human check on outcomes until your own verification layer is solid.
Sources
View the original post on X