OpenAI's Codex now saves a project's setup so every cloud task starts with dependencies installed

Before an agent writes a line of code, somebody has to get the project to build ^[2]. Codex has run tasks in the cloud since its research preview inside ChatGPT in May 2025 ^[7]. According to TechCrunch, OpenAI is making those environments persistent and configurable, where each task used to be an isolated remote sandbox ^[3]. A developer configures the setup once, and each new task starts from it with dependencies already installed ^[1].

The pitch at DevDay was a long list of Codex features: voice control in the command-line tool, an /agents view for tracking several tasks, a code review screen in the ChatGPT desktop app, a security scanner and API updates ^[9]. The work this release does is plainer. Codex reads a connected GitHub repository, works out which software versions the project relies on, and drafts the install script and startup checks from what it finds ^[12]. OpenAI's documentation says the developer revises them in conversation with Codex ^[12].

I think most teams pick a coding agent by comparing models. This release puts OpenAI's effort into the part that comparison skips. Each task launched from a published environment gets its own virtual machine and keeps running while the developer's computer sleeps ^[4]. Unsent changes stay with the task, so it can be reopened from a phone or a browser, and dependency caches survive the background refreshes that keep the repository current ^[5]. OpenAI said the environments are designed to help tasks start more quickly ^[8]. Neither report includes a measured start time.

Team rollouts get decided in the sharing settings. Once an environment is shared with a ChatGPT workspace, colleagues can launch their own tasks from it. They cannot see anyone else's tasks or edit the setup, and enterprise administrators grant editing separately ^[6]. Credentials come as ordinary environment variables or as network secrets. With a network secret, the program sees a placeholder and a proxy inserts the real value only for traffic to an allow-listed domain ^[13]. A shared environment can ask each user to supply their own values from a personal account ^[13]. Internet access starts at a preset of common package registries and can be opened wider ^[14]. I'd expect whoever holds edit rights to end up owning every colleague's install script and allow list, whether or not anyone writes that into a job description.

The limits depend on repository host and plan. Cloud environments cannot yet work with repositories on GitLab or self-hosted GitHub Enterprise Server, and computer and browser use are unsupported ^[17]. The new code review screen does handle GitLab merge requests ^[11]. A GitLab shop can therefore get Codex reviews but not the environments ^[18]. Plus accounts run on the smallest virtual machines, with half the processors and memory of the Pro, Business and Enterprise tiers ^[15].

For the Monday decision, place the project on two axes. One is setup cost: how long a clean machine takes to install dependencies and pass startup checks. The other is headcount: how many people run tasks against the same repository. High setup cost with many people is the case OpenAI is pitching, teams that want everyone on one approved configuration ^[10], and the first job there is naming who holds edit rights ^[6]. High cost with one developer gets the cached dependencies and the cross-device state ^[5], with little to govern. Low cost with many people buys consistency and the secrets proxy ^[13] more than speed. Low cost with one developer changes little. The grid assumes the code sits on hosted GitHub; a GitLab or self-hosted GitHub Enterprise Server repository falls outside it for now ^[17].