Developer data protection
OpenAI
Separate setup secrets from agent variables
Codex cloud documents environment variables for the full chat and secrets available only to setup scripts, removed before the agent phase. Plan which values each phase actually needs, then review any copies your setup creates in files or logs. Use only fake values for a scoped verification; this guide does not create or run a cloud environment.
For Cloud-development administrators
Variable availability and copies created by setup are separate questions.
Synthetic values and unexecuted cloud checks. No environment or provider task is launched.01
Name the phases before choosing a value type
Codex cloud creates a container, checks out the selected repository, runs setup and then begins the agent phase. Current documentation says setup has internet access while agent internet access is off by default unless configured. The environment owner should understand that sequence before supplying credentials.
List why each value is needed. A private dependency credential used during setup has a different purpose from a non-sensitive flag required throughout the task. Do not make a value available for the full chat simply because it is convenient to read from the same variable name in every phase.
Source context: OpenAI: Cloud environments
02
Use the documented phase distinction
OpenAI documents ordinary environment variables as available during both setup and the agent phase. It documents secrets as additionally encrypted and available only to setup scripts, with removal before the agent phase. Record which mechanism was actually selected in the environment settings.
Setup scripts also run in a separate shell session, so an export performed there does not automatically persist into the agent phase. Treat configuration choices, shell inheritance and secret availability as different mechanisms. This page concerns hosted Codex, not the local CLI process-environment test.
| Value source | Setup phase | Agent phase |
|---|---|---|
| Configured environment variable | Documented available | Documented available |
| Configured secret | Documented available | Documented removed |
| Export only in setup shell | That setup session | Does not automatically persist |
| Copy written by your setup | Review what was created | Do not infer removal from secret-variable handling |
Source context: OpenAI: Cloud environments
03
Review files and logs created during setup
Removing a secret from an environment variable is not the same as removing a copy that a setup step wrote into a configuration file, log or generated artifact. Review those outputs and the tools that produce them. Prefer the organisation’s supported approach for private dependencies without unnecessarily persisting credentials.
Use the artifact register to record potential copies and their owners. Do not deliberately write a real secret into a file to test whether the agent can find it. The bundled example describes a fake setup value and a fictional output path so the decision can be discussed without creating a credential exposure.
04
Use a fake-value phase record
In an approved disposable environment, a reviewer can record whether a harmless marker is available at each phase. The pack contains a static expected-availability matrix and a blank observation sheet; it does not run Codex, install dependencies or contact a provider. Keep any evidence to marker-presence decisions rather than exporting environment contents.
Establish the configured source of each value before interpreting an absence. If the fake variable was never configured, a missing agent-phase marker does not demonstrate the secret-removal behaviour. Record prerequisites, phase, expected availability and actual observation separately.
Source context: OpenAI: Cloud environments
05
Include cached starts in the approval
OpenAI documents cached container state and an optional maintenance script on resume. It also describes cache invalidation when environment configuration changes. A clean initial setup and a resumed task are different lifecycle observations, so identify whether the test used a new or cached environment.
Close the review with value purposes, phase availability, generated-copy handling and the environment owner’s decision. Recheck when setup, maintenance, variables or secrets change. The result does not approve a local CLI, remote SSH workspace or every future environment using the same repository.
Source context: OpenAI: Cloud environments · OpenAI: Agent approvals and security
Put it into practice
Codex cloud value-availability review
Separate documented phase availability from generated copies and your own observations.
Synthetic values and unexecuted cloud checks. No environment or provider task is launched.
Setup
Repository checkout and approved dependency preparation
Configured secrets are documented as available here
Agent phase
Task tools and configured agent network policy
Configured secrets are documented as removed
Retained state
Files, logs and cached environment created during setup
Review copies independently
| Value or copy | Expected from documentation | Observed |
|---|---|---|
| Ordinary configured variable | Setup and agent phases | Untested |
| Configured setup secret | Setup only | Untested |
| Setup-shell export | Does not automatically persist | Untested |
| Generated file or log | Requires its own review | Unreviewed |
| Cached environment resume | Record lifecycle and maintenance | Untested |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
README.mdInspect
# Codex cloud phase review
Static review pack. No cloud task, provider call, dependency install or active setup script is included. All value labels are fake. This is separate from the local CLI D06 fixture.
1. Record the purpose and selected configuration mechanism for each synthetic marker.
2. If an authorised reviewer chooses to observe an approved disposable cloud environment, record marker presence only, not environment values or real credentials.
3. Complete observations.csv for setup, agent phase and any cached resume. A missing marker is not meaningful until its configured source is established.
4. Review generated files/logs independently in generated-copies.md. Do not write a real secret to disk for this exercise.
## Guide and sources
Canonical guide: https://aona.ai/resources/guides/codex-cloud-setup-agent-secrets/
Source review: 2026-09-21
- OpenAI: Cloud environments: https://learn.chatgpt.com/docs/environments/cloud-environment
- OpenAI: Agent approvals and security: https://learn.chatgpt.com/docs/agent-approvals-security
synthetic-phase-values.jsonInspect
{
"notice": "FAKE LABELS; NOT ACTIVE ENVIRONMENT CONFIGURATION",
"ordinary_variable": {
"label": "SYNTHETIC_D16_PUBLIC_FLAG",
"purpose": "Non-sensitive task setting"
},
"setup_secret": {
"label": "NOT_A_CREDENTIAL_D16_SETUP",
"purpose": "Illustrative setup-only value"
},
"generated_copy": {
"path_label": "SYNTHETIC_OUTPUT_FILE",
"status": "NOT_CREATED"
},
"cloud_tests_performed": false
}
expected-availability.csvInspect
reviewed_at,value_source,setup,agent_phase,source
2026-09-21,Configured environment variable,Available,Available,https://learn.chatgpt.com/docs/environments/cloud-environment
2026-09-21,Configured secret,Available,Removed,https://learn.chatgpt.com/docs/environments/cloud-environment
2026-09-21,Export only in setup shell,Setup session only,Does not automatically persist,https://learn.chatgpt.com/docs/environments/cloud-environment
2026-09-21,Copy created by custom setup,Review independently,Review independently,Review your setup implementation
observations.csvInspect
environment_version,new_or_cached,value_label,configured_source_confirmed,phase,expected,observed_marker_presence,evidence
RECORD,RECORD,SYNTHETIC_D16_PUBLIC_FLAG,UNVERIFIED,setup,Available,UNTESTED,
RECORD,RECORD,SYNTHETIC_D16_PUBLIC_FLAG,UNVERIFIED,agent,Available,UNTESTED,
RECORD,RECORD,NOT_A_CREDENTIAL_D16_SETUP,UNVERIFIED,setup,Available,UNTESTED,
RECORD,RECORD,NOT_A_CREDENTIAL_D16_SETUP,UNVERIFIED,agent,Removed,UNTESTED,
generated-copies.mdInspect
# Setup output review
Setup/maintenance owner: ____________________
Value purpose and source: ____________________
Files that could receive configuration values: ____________________
Logs or tool outputs that could receive values: ____________________
Cached state to review: ____________________
Supported handling/removal process: ____________________
Evidence: UNREVIEWED
Decision: NOT YET REVIEWED
This record creates no output file or retained copy. Do not put real secret values in it.
Before you proceed
Keep these distinctions clear
- Using an ordinary variable for a setup-only credential
- Choose the documented mechanism according to the required phase, not convenience.
- Assuming removed variables imply removed files
- Review any copy made by setup, build tools or logging as its own artifact.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate supported employee endpoint data paths used alongside a coding workflow.
This is a Codex cloud configuration guide, not a claim that Aona enforces hosted setup or secret removal. No agentless cloud control is implied.
Keep the hosted phase review with the environment owner and scope any relevant installed-endpoint protection separately.
Review your use caseFAQ
Questions for this decision
Are configured Codex cloud secrets available to the agent phase?
Are ordinary environment variables treated the same way?
Does an export in the setup shell persist automatically?
Does this procedure prove setup-generated files contain no secrets?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- OpenAI: Cloud environments
Documents setup/agent phases, variables versus secrets, shell-session separation and cached lifecycle.
vendor · checked 2026-09-21 - OpenAI: Agent approvals and security
Explains distinct local/cloud execution and network boundaries.
vendor · checked 2026-09-21