On September 7, TestingCatalog reported that OpenAI's codebase now contains a Managed Agents feature: create agents, create environments, run agent sessions, attach skills and plugins, all on the OpenAI Platform, with self-hosted environments alongside cloud ones. DevDay is September 29 at Fort Mason. Nothing is announced yet, so treat this as a codebase reading rather than a product page.
The shape is not new, though. Anthropic's Managed Agents docs define an Environment as "configuration for where sessions run: an Anthropic-managed cloud sandbox, or a self-hosted sandbox on your own infrastructure," and a Session as "a running agent instance within an environment." Swap the vendor name and that is the object model TestingCatalog describes.
OpenAI already had half of it. The April Agents SDK update, as Help Net Security covered it, shipped native sandbox execution with seven hosted providers: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, and Vercel. The same coverage quoted OpenAI's own caveat that managed agent APIs "place limits on where agents run and how they access sensitive data." Five months later the company appears to be building the managed layer anyway.
The box is now the product
Strip the vendor names and the industry has converged on one primitive: a container per session, provisioned by the platform, where the agent's tools execute. The model runs in one place, the harness in another, and the filesystem, shell, and network egress sit in a box you rent or host.
That is a sensible design. It also turns two formerly trivial questions into real ones.
The first is observation. When an agent ran on your laptop, you watched the terminal. When it runs in a sandbox the platform provisioned, you get an event stream. Anthropic's docs describe results arriving "through server-sent events" with history "persisted server-side." That is a log, not a terminal, and the difference matters when a build hangs at minute forty or a test runner is silently waiting on stdin.
The second is reachability. A session in a hosted sandbox sits behind NAT you did not configure. Anthropic's self-hosted sandbox docs say the worker "needs only outbound HTTPS." That is a feature for the ops team and a wall for anything that wants to reach the agent: another agent in a different vendor's box, a developer's machine, a GPU node elsewhere. Nothing dials in.
Seeing into the box
Observation is the case shell.online exists for. The CLI wraps any process in a PTY, and one command produces a browser link and a password. The README states the boundary: the process and PTY stay on the machine running the command, and the CLI encrypts terminal frames before Cloudflare relays them. Cloudflare sees connection and lifecycle metadata, not terminal input or output. The same holds for whichever platform owns the sandbox: its network path carries ciphertext.
For agents, the --json flag returns one structured event with the session ID, share URL, end-to-end encryption password, and flags for read-only, encrypted, and background. An agent in a managed session can start a build under shell.online, hand the operator the link and password in the conversation, and keep working. The operator opens it on a phone and sees the actual PTY. With --read-only, browser input is rejected at the Worker, which is the right default when the viewer is a reviewer rather than a driver.
The Docker entrypoint in the repo shows how this survives the sandbox lifecycle. It keeps the encryption password in a mode-600 file on a state volume, exits if a configured password does not match the stored one, prints the password to stderr with the note that it is never sent to shell.online, then runs the CLI with --foreground --persistent against a session file on the same volume. Restart the container and the URL and password are unchanged. A per-session sandbox needs exactly that: a link to the terminal that outlives the container it is in.
Three releases went out today, 0.9.0 through 0.10.1. The relevant one adds shell login, which links a machine to an account so sessions started from the CLI appear in a web app next to sessions from every other linked machine. Ten agent sessions on ten linked machines, one page.
Reaching out of the box
Reachability is the Pilot Protocol problem, and hosted sandboxes make it sharper. The point of a managed environment is that you do not control the network. You get outbound connectivity, an ephemeral address, and someone else's NAT.
Our design assumes that. An agent talks to a local daemon over a Unix socket. The daemon holds an Ed25519 identity, does Ed25519-signed X25519 key exchange, and protects payloads with AES-256-GCM. A rendezvous service handles discovery and NAT traversal through STUN and hole-punching, and the README states the constraint plainly: once a tunnel is up, "the rendezvous is not in the data path, except when the beacon must relay traffic for peers behind symmetric NATs (relayed traffic stays end-to-end encrypted)." Behind a NAT you cannot configure, hole-punching fails more often, so the relay path is the one to plan for, and it still cannot read the traffic.
Given outbound UDP from the sandbox, an agent in an OpenAI environment, one in an Anthropic environment, and one on a laptop hold addresses in the same 48-bit virtual space and open authenticated streams to each other without any of the three platforms in the conversation. The daemon takes PILOT_REGISTRY, PILOT_BEACON, and PILOT_SOCKET from the environment, which the README lists for containerized deployments.
Trust is bilateral and off by default. Nodes begin private and a peer becomes reachable only after a signed mutual handshake, so a sandbox full of agents is not a sandbox full of open ports. That is a different posture from an MCP server behind a bearer token, and it is the one you want when the agents run code you did not write in boxes you do not own.
What to watch on September 29
Whether OpenAI ships self-hosted environments on day one. TestingCatalog's reading says yes, and Anthropic already does. If both platforms support that mode, the sandbox becomes the one piece of the stack the customer controls, and both questions above, watching the terminal and reaching other agents, become the customer's to answer. The tools for both are open source today. The managed layer was the missing piece, and it is about to stop being missing.
Top comments (0)