OpenAI will acquire Ona to bring secure, persistent cloud execution into Codex for long-running software agents. Review rollout risks today.
What Persistent Codex Agents Change
OpenAI’s move to acquire Ona is aimed at one gap in agent tooling: most coding agents still treat the environment as disposable. A session ends, the shell is gone, and the next run rebuilds context from scratch. Persistent cloud execution flips that model. An agent can keep a long-lived workspace, resume unfinished work, and carry forward installed tools, partial builds, and local state across hours or days instead of a single chat turn.
For Codex, that means agents can take on multi-step software work that does not fit a short interactive loop—refactors that span many files, test-and-fix cycles, dependency upgrades, or migrations that need overnight soak time. Persistence is not just convenience. It is the difference between a helper that answers questions and a worker that can own a task until it is done or blocked.
Ona’s role in this picture is secure, durable cloud execution: isolated environments where an agent can run commands, hold secrets under policy, and stay available without tying the workload to a laptop that sleeps or a CI job that times out.
Security and Isolation Tradeoffs
Long-running cloud agents raise a different threat model than one-shot code generation. The agent holds more state for longer, touches more systems, and may store credentials, intermediate artifacts, and network access. Secure execution has to cover isolation between tenants, least-privilege access to repos and APIs, auditability of every command, and clear boundaries on what the agent may write back to production-adjacent systems.
Teams should treat the persistent environment as production-adjacent infrastructure, not a sandbox toy. That implies locked-down outbound network rules, short-lived credentials with scoped roles, encrypted volumes, and explicit policies for what the agent may install or exfiltrate. Persistence without those controls multiplies blast radius: a compromised agent keeps working after the operator has gone offline.
Rollout Risks to Review Today
Before leaning on persistent Codex agents for real workstreams, review operational risk with the same rigor you would apply to a new continuous runner or remote developer machine.
- Cost and runaway jobs: A stuck agent can burn compute, storage, and API quota indefinitely. Cap max runtime, disk, and concurrent environments; alert on idle but live sessions.
- State drift: Long-lived workspaces diverge from clean CI images. Define rebuild and image-refresh cadences so “it worked on the agent” does not become undebuggable snowflake state.
- Secret leakage: Prompt history, logs, and shell history can capture tokens. Prefer injected secrets over plaintext env files, and redact agent output that might include credentials.
- Human approval gates: Require review before merges, deploys, or external side effects. Autonomy should stop at the boundary of irreversible change.
- Ownership and handoff: Assign who is responsible when an overnight agent fails halfway—who resumes, who reverts, and how status is reported.
Practical Guidance for Adopting Persistent Agents
Start with low-blast-radius tasks: lint/fix fix loops, dependency bump PRs, documentation generation, and internal tooling changes behind feature flags. Keep agent workspaces ephemeral enough to rebuild, but persistent enough to finish multi-hour jobs. Encode success criteria in the task brief so the agent knows when to stop rather than thrashing.
Instrument early: capture command logs, exit codes, file diffs, and cost per run. Use those signals to decide which workflows deserve more autonomy. Persistence makes agents useful for long-running software work; discipline around isolation, spend limits, and human gates is what makes that usefulness safe to ship.