September 29, 2026, OpenAI DevDay. Buried in a list of Codex updates — voice-controlled CLI, an /agents view, code review inside ChatGPT desktop — was one line that mattered more than the rest: Codex Cloud environments are no longer thrown away after each run. They’re persistent, shareable objects now. Files, installed dependencies, granted permissions, command history — all of it lives server-side, and you can pick the same environment back up from your laptop, your phone, or a teammate’s machine.

I’ve spent a decade watching this exact argument happen with regular servers, then with containers, then with CI runners. Every time, someone reaches for “let’s just keep the environment around, it’s faster” and someone else reaches for “that’s how you get a box nobody can rebuild.” Both of them are right, which is the annoying part.

The shape of the old argument

Immutable infrastructure won that fight for a reason. A server you SSH into and hand-configure over six months becomes a box only one person understands, and that person eventually leaves. A golden AMI or a from-scratch container build is slower per launch, but it’s reproducible — blow it away, rebuild it, get the same thing. Cold start cost bought you a guarantee: what’s running now is exactly what your config says should be running.

Agent sandboxes had, until last week, quietly inherited that same discipline, mostly by accident. Every Codex Cloud task used to clone the repo, install dependencies, and set permissions from zero. Slow, but you always knew the blast radius: whatever that one task did, in that one throwaway container, gone the moment the task ended.

Persistent environments trade that guarantee for speed and continuity. Which is exactly the trade cold-start containers were invented to avoid making.

Where this actually bites you

The part that should worry a tech lead isn’t the speed gain — that part’s genuinely good, nobody wants to wait for npm install on every single task. It’s what accumulates quietly in a long-lived agent environment that nobody’s watching:

# environment created week 1, task: "fix the login bug"
# → granted: read/write on repo, network access to staging DB

# environment reused week 3, task: "add a Stripe webhook handler"
# → granted: outbound network to api.stripe.com
# (still holds staging DB access from week 1 — nobody revoked it,
#  because nobody re-provisions a sandbox that's "already working")

# environment reused week 6, task: "debug flaky test in payments module"
# → agent now has staging DB + Stripe + whatever the flaky test needed,
#   scoped to a task from three weeks ago that has nothing to do with this one

That’s permission creep, and it’s the exact failure mode config management tools spent the 2010s trying to stamp out on regular servers. A fresh container for every task made this problem structurally impossible — there was no “week 3” for permissions to survive into. A persistent one makes it the default outcome unless someone actively fights it.

The fix isn’t “don’t use persistent environments”

It’s borrowing the part of immutable infra that actually mattered: not the rebuild-from-scratch part, the versioned, auditable state part. If you’re adopting Codex’s persistent environments — or building this pattern yourself for any agent harness — the manifest is the thing to get right, not the container:

# environment.lock.yaml — regenerated every time permissions change,
# diffed in code review like any other config file
environment_id: env_8f3a1
created: 2026-09-15
last_reprovisioned: 2026-09-29
grants:
  - scope: repo:read-write
    reason: "fix login bug — task #4471"
    granted: 2026-09-15
    expires: 2026-10-15   # force re-justification, don't let it go stale
  - scope: network:staging-db
    reason: "fix login bug — task #4471"
    granted: 2026-09-15
    expires: 2026-10-15
  - scope: network:api.stripe.com
    reason: "stripe webhook handler — task #4502"
    granted: 2026-09-22
    expires: 2026-10-22

An expires field on every grant turns “permission that nobody remembers granting” into “permission that either gets renewed with a reason, or quietly dies.” Cheap to implement, and it’s the one thing a from-scratch container gave you for free that a persistent one doesn’t: a forcing function to re-justify access instead of it accumulating forever.

The one thing this genuinely fixes

To be fair to OpenAI’s actual pitch: cross-device continuity is not a small win. Starting a refactor on your laptop, checking its progress from your phone on the train, then finishing it from a different machine at the office — without re-cloning, re-installing, re-authenticating each hop — solves a real, annoying problem that cold-start sandboxes never addressed at all, because they weren’t designed to be picked up mid-task in the first place. That part of the announcement isn’t the golden-AMI debate replayed. It’s a genuine new capability, and it’s the reason persistent environments are worth adopting despite the permission-creep risk, not instead of dealing with it.

Where I land on this

I’d use persistent Codex environments for anything scoped to one project with a small, stable set of people touching it — that’s most day-to-day feature work, and the speed win is real. I would not reuse the same persistent environment across genuinely different tasks that need different access, no matter how tempting “it’s already set up” sounds three weeks in. That’s not a Codex-specific rule. It’s the same rule that applied to the EC2 box your team kept SSHing into in 2016, and it didn’t get less true because the thing running in the sandbox now writes its own code.