Shared Codex Cloud environments as a team governance control
This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.
Shared Codex Cloud environments let a team prepare one approved setup for a repository and have every cloud task start from it. OpenAI launched reusable environments at DevDay on 29 September 2026 and presented them as a shared team setup that carries approved settings and permissions (DevDay recap). For an engineering leader, the environment is the place where you decide what an unattended agent can reach.
This page covers the adoption decision. For step-by-step setup, use the Codex Cloud environments guide, which is the primary source for the controls below.
What does a shared Codex Cloud environment control?
An environment holds the repositories, dependencies, an install script, a start skill, network rules, and credentials. Codex prepares and tests the setup; a person saves and publishes it. Each new task then gets an isolated workspace copied from the published filesystem.
That makes the environment a policy object as well as a convenience. It decides which domains the task VM can reach, which credentials a task can use, and which private network it joins. Everyone starts from the same baseline instead of improvising setup inside individual tasks.
It does not control everything. Repository access and personal connections still depend on the account running the task. In Enterprise workspaces, admins set workspace requirements in Agent Security, and those apply alongside each environment's own domain settings.
Is your team ready for shared cloud environments?
Start with teams that keep their code in GitHub, repeat the same setup across many tasks, and want agents to keep working while laptops are closed. Those teams gain the most from a published baseline.
Wait, or keep the work local, in three cases. The repository lives in GitLab or self-hosted GitHub Enterprise Server. The task needs computer or browser use. Or your data handling rules have not yet been checked against a hosted VM. The docs list the first two as current limitations of cloud environments.
Codex in the cloud is available on Plus, Pro, Business, Healthcare, Education, and Enterprise plans. Sharing with a workspace is documented for Enterprise workspaces. Pro, Business, and Enterprise tasks get 4 vCPUs, 16 GiB of memory, and 32 GiB of disk by default, and Plus gets 2 vCPUs. Local and cloud work share one usage allowance, and cloud tasks may use more of it.
Which controls need an owner?
| Control | Where it is set | Suggested owner | Check before sharing |
|---|---|---|---|
| Who can use the environment | Privacy > Who can use: Only me or the workspace | Environment owner | The setup is tested and published |
| Creating and editing shared setups | Manage workspace environments permission | Platform or DevEx lead | Only a few people can change the baseline |
| Running cloud tasks | Use Codex in the cloud permission | Engineering manager | Access matches who should delegate work |
| Network destinations | Allow domains preset and additional allowed domains | Security with repo owner | Starts from Package managers, not All (unrestricted) |
| Service credentials | Network secrets with allowed domains | Repository owner | Each token is limited to the HTTPS hosts that need it |
| Per-person values | Personal vault | Each engineer | The environment requests keys, never someone's actual values |
| Private network and cloud identity | VPN (Tailscale) or OIDC (Enterprise, by request) | Platform team | The shared identity has only the permissions the work needs |
| Workspace ceiling | Agent Security, set by Enterprise admins | Security | Environment settings stay inside workspace policy |
Two details belong in your written policy. Access to a shared setup does not grant access to someone else's task or permission to edit the environment. And editing a shared OIDC connection can affect every other environment that uses it.
Where are the risks in a shared setup?
Environment-owned credentials come first. An environment variable is passed straight to programs and its value is visible to the task. A network secret reaches programs only as a placeholder, which the proxy replaces for allowed HTTPS destinations. Make network secrets the default, and review prepared files and environment-owned credentials before sharing, as the guide advises.
Broad egress is the second risk. All (unrestricted) makes setup easier and review harder. Saving an environment-owned network secret also adds its destinations to restricted internet access, so re-read the saved network policy after every new secret.
Shared identities are the third. Tasks in a shared environment use its configured VPN identity. With OIDC, the identity's permissions decide access, and personal provider permissions do not transfer to it. Treat both like service accounts. The guide recommends testing one allowed and one denied operation after attaching OIDC.
Stale baselines are easy to miss. Existing tasks keep their own state after a republish, so a setup fix reaches only new tasks. Announce republishes in the team channel.
Delegation from chat widens the audience. In Enterprise workspaces with Cloud delegation enabled, a request to @ChatGPT in Slack or Microsoft Teams can pick any environment shared with the workspace. Every environment you share becomes a candidate for those requests.
Rollout checklist
- Choose one GitHub repository with an active owner and a steady flow of small tasks.
- Let that owner create the environment, keep Who can use on Only me, and publish it.
- Set internet access to Package managers plus named hosts, and move every token into a network secret with allowed domains.
- Run a handful of ordinary tasks from it, and note each setup failure and each access request.
- Limit the Manage workspace environments permission, then share the environment with the workspace.
- Write down who approves new domains, new secrets, and republishes, and review that list every month.
What should you measure?
Measure setup friction and control, not the number of tasks. Record how often tasks fail on missing tools or blocked domains, how many new domains people request, and how long reviewers spend on cloud-produced pull requests compared with local ones. Keep the definitions from our pilot measurement guide so the comparison stays fair.
Cloud tasks finish while nobody is watching, so the evidence a reviewer receives matters more than before. The checklist in From AI-generated code to a reviewable change applies unchanged. Our free methodology guide explains Delegate, Review, Own, and AI training for teams can run the pilot on your own repositories.
Pick the pilot repository this week and name its environment owner before anyone shares a setup with the workspace.