Codex cloud runs each task in its own workspace from a saved environment that holds repositories, tools, and access. Network access is configurable, with presets and extra allowed domains, and network secrets supply credentials for allowed HTTPS services. OpenAI's guidance is to use network secrets and limit the environment's network destinations.
What an environment contains
OpenAI's Codex cloud documentation describes an environment as the repositories, tools, and access a project needs. Settings shown include repository, secrets, outbound identity, network, package managers, an install script, a start skill, and access. For a new environment, Codex inspects the selected GitHub repositories, installs dependencies and tools, and tests the workflow, then asks you to review the setup and test results before publishing. Tasks can start once the environment is published, and multiple tasks can start from one published environment. Each task has its own workspace and can keep running while your computer is asleep.
Internet access in the agent phase
A separate page, labeled for the legacy cloud product, describes the model of two phases. Setup scripts run with internet access so they can install dependencies. The agent phase blocks internet access by default, and you can turn it on per environment.
| Setting | Behavior |
|---|---|
| Internet access Off | Blocks all internet access in the agent phase |
| Domain allowlist: None | Empty list, you add domains |
| Domain allowlist: Common dependencies | Preset of package, source control, and build domains plus your additions |
| Domain allowlist: All | Unrestricted |
| HTTP methods | Recommended to limit to GET, HEAD, and OPTIONS, which blocks POST, PUT, PATCH, and DELETE |
The page lists the risks that motivate the controls: prompt injection from untrusted web content or dependency READMEs, code or secret exfiltration, downloading malware or vulnerable dependencies, and pulling in content with license restrictions.
Network secrets
The current cloud page describes network secrets as credentials for allowed HTTPS services, and advises using them while limiting the environment's network destinations. It notes that saving a network secret also allows access to its domains. That is a design detail to remember: adding a secret widens the network list by that host.
Environment variables and OIDC connections can also be configured. The page does not describe how secrets are exposed to setup versus agent phase, and the legacy internet access page also does not. Ask OpenAI or read current documentation before assuming a separation exists.
A worked example: setting up an environment
An illustrative setup for a service with a private package registry.
- Start with Off. Create the environment and run the install script. Note the failure because the private registry is unreachable.
- Allow the registry in the setup phase. Use the setup script's own network access for installation. Do not widen the agent phase yet.
- Run a task. Check whether the agent needs anything beyond the installed dependencies.
- Add a network secret only if needed. If tests call an internal HTTPS API, add a secret for that host. Remember it also allows that host.
- Limit methods. Where the setting exists, restrict to read methods for the agent phase.
- Set privacy. Choose who can use the environment, such as only you or everyone in the organization.
- Review. Read the setup results and publish.
Risks to plan for
| Risk | Control |
|---|---|
| Injected instructions in dependency documentation | Default deny, read-only methods, review |
| Data sent to an allowed host | Narrow destinations, scoped credentials |
| Unreviewed changes | Review the diff and test results before commit or pull request |
| Over-shared environments | Restrict who can use each environment |
| Stale setup state | Update the environment as the project changes |
The documentation says you review changed files and test results, ask for follow up changes, and then commit or open a pull request. Make that review real. For workflow files, build scripts, and dependency manifests, read them first.
Questions to ask before enabling it for a sensitive repository
- Which phase can see secrets, and where is that documented?
- What can the model channel carry?
- What is retained, and for how long?
- How are environments shared, and who can edit them?
- Is there an audit trail of tasks and network blocks?
Governance for shared environments
An environment is reusable, which is its strength and its risk. Several tasks start from one published environment, so a change to the environment affects every later task.
- Name an owner. One person or team approves changes to each environment.
- Version the setup. Keep the install script and settings in a place where changes are reviewed, even if the product holds the live copy.
- Limit who can use it. The privacy setting controls whether an environment is only for you or for everyone in the organization. Use the narrow choice for sensitive repositories.
- Review secrets quarterly. For each network secret, confirm the host, the owner, and that the credential is still scoped as intended.
- Remove stale access. When a project ends, archive the environment and revoke its secrets.
- Test after changes. Run a task that tries to reach an unlisted host and see that it fails.
What to record for auditors
| Item | Why |
|---|---|
| Environment name, owner, purpose | Accountability |
| Repositories attached | Scope of code exposure |
| Network setting and allowed domains | Egress posture |
| Network secrets and their hosts | Credential exposure |
| Install script version | Supply chain evidence |
| Who may use the environment | Access control |
| Date of last review | Currency |
Keep this in a short register. It answers most of what a customer questionnaire or internal review will ask about agent environments.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how fix pull requests are produced and presented for review, since cloud agent output arrives the same way.
Where Safeguard fits
Safeguard does not run Codex. It offers a Local agent and a Cloud agent, both listed as Available on its download page, and its CLI can write code as well as scan. Its policies, gates, and autonomous remediation with fix pull requests, which is off by default with every category on Manual, apply to changes however they are produced.
Quick check
Does saving a network secret change the network list?
Yes. The page says saving a network secret also allows access to its domains, so adding one widens the list by that host.
Can the agent phase reach the internet by default?
Per the legacy page, no. It blocks internet access in the agent phase by default while setup scripts have access, and you can enable it per environment.
Is it documented which phase can read secrets?
Not on the pages we reviewed. Check current OpenAI documentation before assuming.
Sources
- Codex cloud (OpenAI documentation)
- Codex cloud internet access (OpenAI documentation)
- Safeguard download page
Last reviewed: 19 October 2026.
