Separate setup secrets from agent variables

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.

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 setup-output review form 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