At DevDay on September 29, OpenAI announced reusable development environments for Codex Cloud. When a developer selects a GitHub repository, Codex investigates and installs the dependencies and development tools it needs, then verifies that everything actually works. The prepared environment can then be "Published" as a state that new tasks can start from repeatedly.
Each task gets its own isolated workspace, and processing continues in the cloud even if your local PC goes to sleep. You can also reopen the same task from the web, mobile, or desktop and pick up where you left off.
What matters about this change is not just that environment setup can be handed off to AI. Developers can now manage the whole development environment: which state is reused across multiple tasks, how far each task's changes stay independent, and with what permissions tasks connect to internal services.
Updating an environment and republishing it does not change the work in tasks that are already running. And even when a credential itself can be hidden from the agent, the permissions the service has granted to that credential are not narrowed.
Let Codex prepare the development environment
Creating a new cloud environment starts with choosing a GitHub repository.
Codex examines the repository, identifies the runtimes, packages, development tools, and services it needs, installs dependencies, and tries out the development workflow. If it cannot determine the access rights or configuration values required, it asks the user, so the process does not rely solely on guesswork.
The user reviews what Codex prepared and the test results, makes any necessary corrections, and then Publishes the environment so it can be used by new tasks.
You can adjust the environment through conversation with Codex. For example, you can tell it to use a specific version of Node.js or Python, or add services and commands you need.
The setup steps Codex confirms are recorded mainly as two settings:
- Install script: Commands that prepare dependencies and the files needed for development
- Start skill: Steps that start services and confirm they are running properly
In other words, instead of a person writing a complete setup script before assigning a task, you can have Codex build the environment, try it out, and consolidate it into reusable settings.
That said, running code in the cloud and having Codex install dependencies automatically are not new in themselves.
The previous Codex Cloud already offered automatic setup, manual setup scripts, container caching, and similar features. The major change this time is that an environment prepared and verified together with Codex can be saved as a single reusable configuration and serve as a common starting point for multiple independent tasks.
Once an environment is in place, it may reduce the burden of preparing the same dependencies and tools from scratch every time you start a new task.
The earlier approach remains available as "Codex Cloud (Legacy)," and it continues to support integrations with Code Review, Linear, and GitHub. OpenAI says it plans to retire the legacy approach in the future, but current documentation does not give a specific end date.
The arrival of the new reusable environments does not mean every existing integration has moved over at the same time.
Tasks start from a shared environment but their work stays independent
A new task starts from the prepared filesystem of the Published environment.
However, changes made in the task are not automatically written back to the original environment. Each task gets its own isolated workspace.
OpenAI's specifications can be summarized as follows:
| Item | Initial state | Subsequent changes |
|---|---|---|
| Published development environment | Filesystem prepared and verified by Codex | Becomes the common starting point for new tasks |
| Individual task | Isolated workspace created from the Published environment | Uncommitted changes and added tools remain only in that task |
| New task after the environment is updated and republished | Updated filesystem | Not reflected in tasks that existed before the update |
For example, if you add a testing tool partway through a task, that change is not automatically added to other tasks or to environments your colleagues use.
If you want the tool available in future tasks, you need to open the environment settings, have Codex prepare and test the change, and republish.
Meanwhile, tasks already in progress are not overwritten by the new environment. Uncommitted code changes and tools added within the task are kept as that task's own state.
This lets you update a shared development environment without breaking work in progress.
The differences among "Save," "Publish," and "Share" also matter here.
Save stores the environment's settings, and some changes are reflected immediately in the environment being prepared. Publish finalizes the prepared filesystem at that point as the starting point for new tasks. Share determines who can use the environment.
So "Publish" here does not mean making something public.
Even if an Enterprise shares an environment with a workspace, other users do not gain the ability to view working files inside someone else's tasks. Being able to use a shared environment is also a separate permission from being able to edit it.
By default, a task's VM state is kept in a restorable form for up to seven days from the last time processing was started or resumed.
However, this does not mean a task runs continuously for seven days, nor that files are stored permanently.
Background repository updates maintain the dependency cache, but they do not automatically rerun the Install script or Start skill.
Code and artifacts you want to keep need to be committed to Git or explicitly saved somewhere appropriate.
Connect to HTTPS services without handing over the credential itself
In the current Codex Cloud, you can choose between ordinary environment variables and "Network secrets" for passing credentials and configuration values.
Ordinary environment variables are for cases where a program needs to read the value itself. The value you set is passed directly to programs in the environment.
Network secrets, on the other hand, are for cases where a credential must be sent to a specific HTTPS service but you do not want the secret value itself exposed to processes in the environment.
When you configure a Network secret, programs handle a placeholder string rather than the real credential. When an HTTPS request is sent to an allowed destination, a proxy on OpenAI's side replaces that string with the actual credential.
For example, this method can be used for tokens needed to fetch dependencies from internal or external private package registries.
Network secret substitution works only for HTTPS traffic on port 443 to allowed destinations, both during environment setup and during normal task execution.
The secret value itself is never placed in local processes or files.
If a program itself needs to read the credential's value directly, you need to use an environment variable rather than a Network secret.
In the previous Codex Cloud, secrets registered in encrypted form were used mainly during setup and were removed from the environment before the agent began processing.
With current Network secrets, authenticated HTTPS communication is possible while a task is running, without passing the secret value itself to the agent.
However, hiding a credential is a separate matter from limiting the operations that credential can perform.
For example, if an API token has permission to modify data, hiding the token string from Codex does not automatically prevent writes through that API.
Credentials also differ in whether they are used across the whole environment or supplied by each individual user.
Environments shared in an Enterprise can require the necessary credentials from each user. Sharing an environment does not share credentials an individual has stored in their Personal vault.
Of the values registered in a Personal vault, only those the environment requests are passed to that user's tasks.
On the other hand, Network secrets, cloud identities, VPN connections, and the like owned by the environment itself can become a means of accessing common services from the shared environment.
When sharing an environment within an organization, you need to check not just the prepared files but also the credentials and destinations tied to the environment.
To reach internal services, separate network path from operational permissions
To connect from a Codex Cloud VM to internal services, VPN connectivity using Tailscale is currently available.
This lets cloud tasks reach HTTP and HTTPS services that cannot be accessed directly from the internet, such as internal APIs and private package registries.
There are limits to what is supported, however.
Tailscale connections use IPv4 addresses or hostnames that resolve to IPv4. Subnet routes for private IPv4 are supported, but private DNS is not added. Database-specific protocols and SSH are also outside the scope of this VPN feature.
Even if your local PC is connected to a VPN, that connection state is not automatically carried over to the Codex Cloud VM.
When connecting to cloud services, short-lived credentials via OpenID Connect (OIDC) can also be used.
Once a company configures a trust relationship with the cloud service, a Codex task can obtain short-lived credentials only when needed. The administrative privileges the user personally holds on the cloud service are not transferred to the task.
Which operations are allowed is determined by the OIDC identity and permissions the company configures on the cloud side.
As of September 30, 2026, OIDC is available on an application basis for Enterprise and must be enabled by an OpenAI representative.
The key point is that being able to reach a network is separate from having permission to use the service.
Even if a VPN lets tasks communicate with an internal API, authentication to that API is not automatically completed. And even if authentication succeeds, granting broad permissions to that identity widens the range of operations Codex can perform.
In a shared environment, each task uses the VPN identity configured there. So "who can use this environment" and "how far into the company that VPN connection can reach" need to be designed together.
Enterprise Agent Security lets organizations manage network and runtime restrictions on these environments through additional policies.
However, restricting one type of traffic does not simultaneously disable every form of external access Codex can use.
For example, network traffic generated by commands, web search, apps and connectors, and MCP servers are each managed by different mechanisms and settings.
Even if you think you have "blocked the network," you need to check which communication paths were actually restricted.
Why this distinction matters is also clear from outside research on past versions of Codex Cloud.
In a technical report published September 16, Tomer Niv of Tego described tests of Codex Cloud conducted from March to June 2026.
In the experiment, instructions embedded in external content entered the agent, and a task influenced by those instructions modified files in the repository. When a later task used an unreviewed branch containing that change, the setup process executed the code and was able to send secrets configured for the test to an external destination.
This is an example of how, even when the agent's own processing is restricted in network and secret access, problems can cross that boundary if a separate environment-preparation process holds different privileges.
However, the tests did not target the newly announced reusable environments.
According to Niv, a retest at the end of August could not reproduce the earlier behavior. At the same time, OpenAI did not give a clear explanation of which parts were fixed, and Niv said that at the time of the report the state of the fix for the overall problem could not be confirmed.
This is therefore not evidence that the same attack works in the new Codex Cloud environments. As a past case, it suggests that task execution, environment setup, network access, and credentials are better not treated as a single privilege.
Even in the cloud, there is a limit to what you can delegate
The standard VM configuration assigned to a Codex Cloud task varies by ChatGPT plan.
| ChatGPT plan | vCPU | Memory | Disk |
|---|---|---|---|
| Plus, Edu Plus | 2 | 8 GiB | 8 GiB |
| Pro, Business, Enterprise | 4 | 16 GiB | 32 GiB |
| Edu, Edu Pro | 4 | 16 GiB | 32 GiB |
Enterprise customers can contact OpenAI about larger VMs and custom specifications.
Being able to keep working in the cloud after closing your PC is a separate matter from being able to handle large builds or large volumes of data.
When using it for real projects, you also need to check whether the memory and disk space required, including dependencies, fit within the standard VM.
Some features are still unsupported.
As of September 30, 2026, Cloud environments do not support computer use or browser use. GitLab and self-hosted GitHub Enterprise Server are also unsupported.
Skills stored in a repository can be used from cloud tasks, but personal Skills saved only on your local PC are not automatically synced to Codex Cloud.
That means you cannot simply move browser-based verification you do locally, or development workflows built around an internal Git server, over to Codex Cloud as is.
The basic flow OpenAI envisions is to start an independent task from a prepared environment, let Codex make changes and run tests, and then have a person review the results before moving on to a commit or pull request.
When considering adoption, you would first check whether Codex can reproduce your project's dependencies, whether it can connect only to the necessary internal services with appropriate permissions, whether testing and verification can be completed within the cloud VM, and whether the final changes can be returned to Git and handed off to your normal review process.
For development work that meets these conditions, Codex Cloud offers a way to move from building an environment on your local PC each time you run a task to reusing a prepared environment across multiple independent tasks and delegating work regardless of whether your PC is running.