The OpenAI Ona acquisition, announced on June 11, 2026, takes aim at the most awkward question hanging over background coding agents: where do they live when you’re not watching them? OpenAI has agreed to acquire Ona, the company behind secure, reproducible cloud development environments, and it’s unusually explicit about why. Codex assignments are getting longer, and my reading of OpenAI’s own documentation (a 12-hour container cache, covered below) is that the current run-it-in-a-container model wasn’t built for work that stretches across days.
In this piece I’ll walk through what both companies actually announced, why Ona’s infrastructure lines up with what Codex is missing, how the deal repositions OpenAI against GitHub Copilot’s cloud agent, and the questions existing Ona customers should be asking before the deal closes.
What OpenAI and Ona Announced
The facts first. OpenAI announced an agreement to acquire Ona on June 11, 2026. The deal isn’t done: the official announcement notes the transaction remains subject to customary closing conditions and required regulatory approvals. Once it closes, Ona employees are expected to join OpenAI’s Codex team — which tells you up front that this is a Codex play, not a standalone product bet.
Ona’s side of the story matches. In its own announcement, the company says OpenAI and Ona will operate as separate, independent companies until the acquisition closes, and that it will continue supporting customers under its existing commitments until then.
Both posts focus on intent, not terms. Neither announcement gives a price, a payment structure, an expected closing date, or a count of how many employees are making the move. For most readers those are trivia. For Ona’s enterprise customers, the closing date in particular is a real planning input, and I’ll come back to why later in this piece.
Why the OpenAI Ona Acquisition Makes Sense for Codex
The numbers OpenAI shared explain the urgency. The company says more than 5 million people use Codex weekly, representing 400% growth from earlier in 2026. More interesting than the user count is the shape of the work: OpenAI says its increasingly valuable Codex assignments now run for hours or days rather than minutes.
That second sentence is the whole acquisition in miniature. An agent that works for ten minutes can live in a throwaway container. An agent that works for three days needs somewhere durable to exist — with the repository, the toolchain, the credentials, and the partial work it has produced so far. OpenAI says it intends to use Ona’s technology so Codex agents can continue working in customers’ cloud environments after users close their laptops. That phrase — “in customers’ cloud environments” — is doing a lot of quiet work, and I’ll unpack it in the enterprise section below.
Ona brings real scale to the table too. OpenAI credits the company with providing secure, reproducible cloud development environments to 2 million developers. And Ona reports that its weekly production-agent sessions grew thirteenfold between the start of 2026 and the announcement. Treat that one as vendor-reported momentum rather than audited fact, but it’s directionally consistent with the adoption curve I documented in my piece on how AI coding agents reshaped developer workflows in 2026.
How Codex Cloud Tasks Run Today
To understand what changes, you need the current baseline. According to OpenAI’s Codex cloud documentation, every cloud task starts the same way: Codex creates a container and checks out the repository revision you selected. Fresh environment, fresh checkout, per task.
There’s already some continuity in the system. Codex caches cloud-container state for up to 12 hours to accelerate new tasks and follow-up work. So the popular framing that Codex agents “lose everything between tasks” overstates the problem. But be honest about what a 12-hour cache is: a performance optimization, not an architecture for multi-day work. When the cache expires, the environment is gone. And OpenAI’s own description of its most valuable assignments, the ones running for hours or days, already pushes past that window.
Security follows the same disposable philosophy. Codex blocks internet access during the agent phase by default, and administrators who turn access on can restrict it by domain and HTTP method. Deny by default, allowlist deliberately. It’s the same direction OpenAI took at the SDK level, which I broke down in my coverage of the OpenAI Agents SDK sandbox and harness update.
That posture is exactly what you’d want to keep while making environments longer-lived. The hard part is keeping that discipline when the environment survives for days instead of hours, holds real credentials, and touches internal services. That’s the problem Ona built its product around.
What Ona Actually Built
Ona’s product is the missing layer, and its documentation is specific about what that layer does. Ona says each agent receives a cloud development environment containing the project’s toolchain, tests, dependencies, databases, and permitted network access. That’s not a sandbox with a repo checkout — it’s the project’s full working context, provisioned per agent.
Two design choices stand out to me.
Disposable machines, durable context. Ona describes individual execution environments as ephemeral and disposable rather than permanently stateful. The persistence lives a layer up: Ona says its platform can carry agent context, tools, access, and work state across devices, teams, tools, and sessions. Machines come and go; the workflow survives.
Enterprise controls as the product, not an add-on. Ona’s Enterprise offering supports deployment in an Ona-managed customer VPC on AWS or Google Cloud, and its capability list reads like a security review checklist:
- SSO or OIDC authentication
- Organizational secrets
- Audit trails
- Network controls and policies
- MCP usage controls
Below that sits runtime enforcement. Ona says its security system enforces executable, filesystem, network, and memory policies at the kernel level, and that agent executions use scoped credentials and generate records of what ran, what changed, when it happened, and why.
Read that back as an enterprise buyer and the acquisition logic writes itself. The blockers that keep teams from letting agents run unattended overnight aren’t usually about model quality. They’re network isolation, credential scoping, and the ability to answer an auditor’s questions afterward. Ona built that checklist as its core product.
Persistence Means Workflow State, Not Immortal VMs
Here I want to push back on some of the early takes. To be clear, this is my reading of the documentation, not an announced architecture. The lazy summary of this deal is “Codex gets persistent VMs.” That’s not what Ona built. Its execution environments are explicitly ephemeral and disposable. What persists is the workflow: the context, tools, access, and work state the platform carries across sessions.
That distinction shapes what you should expect from the integration. A multi-day Codex assignment under this model probably won’t be a single container running for 72 hours straight. The more plausible shape is a series of disposable environments that each pick up the durable state the previous one left behind: Codex’s existing 12-hour cache extended into something deliberate and policy-controlled rather than a best-effort speedup. Neither company has announced an integration architecture, and nothing published so far says how long workflow state would persist or what retention limits would apply — those are open questions, not settled features.
If that’s where it lands, it’s the right call. Long-lived machines accumulate drift, stale secrets, and attack surface. The same pattern shows up in agentic DevOps pipelines: the systems that hold up in production treat compute as disposable and treat state as the thing worth protecting. Workflow persistence on top of disposable runtimes gives you multi-day continuity without multi-day blast radius.
How the Deal Repositions OpenAI Against GitHub Copilot
Every serious coding-agent vendor is converging on the same question: what does the agent’s home look like when nobody’s watching it? Here’s how the documented models compare today:
| Platform | Where agent work runs | State between tasks | Network controls |
|---|---|---|---|
| Codex cloud tasks | Fresh container with your selected repo revision checked out | Container state cached for up to 12 hours | Internet blocked by default; admins can allow specific domains and HTTP methods |
| GitHub Copilot cloud agent | Ephemeral GitHub Actions-powered environment | Runtime is ephemeral; GitHub documents session context and an optional memory feature that can persist separately | GitHub documents an agent firewall with administrator-controlled allowlists |
| Ona | Per-agent cloud dev environment with toolchain, tests, dependencies, and databases | Environments disposable; platform carries context and work state across sessions | Kernel-level executable, filesystem, network, and memory policies |
GitHub’s Copilot cloud agent performs autonomous background development work in an ephemeral GitHub Actions-powered environment, with support for scheduled and repository-event-triggered automations. The disposable runtime doesn’t mean nothing survives it: GitHub’s documentation describes session context and an optional memory feature that persist independently of the execution environment, plus an agent firewall that administrators can configure. That’s a genuine background agent with enormous distribution behind it.
OpenAI, meanwhile, already markets Codex Automations as an always-on background-work feature for tasks like issue triage, alert monitoring, and CI/CD work. Selling always-on work on top of 12-hour cached containers is a gap between the promise and the plumbing. Ona is the plumbing.
The strategic pattern here is hard to miss, and it’s my framing rather than anyone’s announcement: the model is no longer the whole product. The environment — where the agent runs, what it can touch, and what survives between sessions — is becoming the layer these platforms actually compete on. It’s the simplest explanation for why OpenAI is buying an environment company instead of shipping another model feature.
Questions Ona Customers Should Ask Before Closing
If you run on Ona today — especially a VPC deployment — the announcements give you exactly two commitments: the companies operate separately and independently until closing, and Ona continues supporting customers under existing commitments until the transaction closes. “Until closing” is the operative phrase. Neither company has published a guarantee about what happens after that.
Here’s what I’d want answered, roughly in priority order:
- Product continuity. Does Ona remain available as a standalone product after closing, or does it become Codex infrastructure only?
- Commercial terms. Do current pricing, contracts, service levels, and support commitments carry past the close?
- VPC deployments. Do customer-VPC deployments on AWS and Google Cloud remain available under comparable commercial and technical terms?
- Migration. If the standalone product winds down, what’s the migration path, and how much notice do you get?
- Integration timetable. When does Ona’s technology actually appear inside Codex, and which capabilities make the cut?
My recommendation: ask your account team to put answers in writing now, while the companies are still operating separately and Ona’s existing commitments are in force. Whatever the answers turn out to be, having them on paper before the close beats reconstructing them after it. And if Ona’s environment layer is load-bearing for your CI or agent workflows, sketch a fallback plan even if you never use it.
My Take: Right Infrastructure Bet, Unproven Outcome
Everything in this section is analysis of the announcements and documentation — nobody outside these two companies has run Codex on Ona’s infrastructure yet, including me.
I think OpenAI is buying the right thing. My view is that the hard blockers for background agents on real teams sit less in raw model capability than in everything around the model: where the work runs, what credentials it holds, who can audit it afterward, and whether half-finished state survives until tomorrow. Those are infrastructure problems, and OpenAI just agreed to buy a company whose entire product is that infrastructure.
But none of the payoff is proven. The deal hasn’t closed and still needs regulatory approval. There’s no released integration to evaluate, no independent benchmark of multi-day reliability, and the growth figures on both sides are vendor-reported. What would move my assessment from “right bet” to “it worked” is specific: multi-day Codex assignments completing reliably inside customer-controlled environments, with the audit and policy controls intact, verified by someone who doesn’t work at OpenAI.
What to Watch Next
Watch three signals over the next two quarters: whether the deal clears regulatory review, whether Ona’s standalone product gets a public commitment or a sunset notice, and whether persistent workflow state ships in Codex as a documented feature with stated retention limits. If all three land, long-running background agents stop being a demo and become a deployment decision for your team. That’s the moment to re-evaluate — not before.
Related AI Insights
- OpenAI Agents SDK 2026: Sandbox and Harness Update
- AI Coding Agents in 2026: GPT-5, Claude Code, and What Developers Should Use
- GitHub Copilot Token Billing: What Changed in June 2026
- Claude Managed Agents: Dreaming, Outcomes, and Multiagent Orchestration
- Agentic AI in DevOps: Autonomous CI/CD in 2026
