Some cloud coding agents split a task into a setup phase and an agent phase. Codex cloud documents that secrets are available only to setup scripts and are removed before the agent phase, while plain environment variables last for the whole chat. Test which of your credentials land where.
The two phases
In the Codex cloud documentation, a task starts with a container and a checkout of your repository. A setup script runs, with internet access, to install dependencies and tools. Then the agent runs terminal commands in a loop: it edits code, runs checks and tries to validate its work. The two run in separate Bash sessions, so a shell command such as export in the setup script does not carry into the agent phase unless you persist it, for example in the shell profile or in the environment settings.
That separation is a security feature as much as a convenience. Setup needs broad network access to install packages and sometimes a credential to reach a private registry. The agent phase, which reads untrusted repository content and acts on it, should have far less.
Secrets versus environment variables
The page draws a clear line:
| Item | Available when | Notes from the page |
|---|---|---|
| Environment variable | Whole duration of the chat, including setup and agent phase | Visible to the agent |
| Secret | Setup scripts only | Stored with an extra layer of encryption, decrypted only for task execution, removed before the agent phase |
So a private registry token stored as a secret can authenticate a package install and then disappear before the agent starts. The same token stored as an ordinary environment variable stays in the agent's environment, where a prompt injection could try to read or use it.
Container caching
The page also says Codex caches container state for up to 12 hours to speed up new tasks, and can run an optional maintenance script when a cached container is resumed. For buyers, caching raises two questions that match the state discussion in should a remote sandbox keep state between runs: what exactly is cached, and could anything sensitive in the cache outlive the task that created it. If your setup script writes a credential to disk, a cache could carry it forward even when the secrets feature itself removed the original value.
What this means for your design
- Prefer secrets over variables for anything used only during installation.
- Do not write secrets to files in setup scripts unless you delete them in the same script.
- Give the agent phase narrow tokens, such as one that can only open pull requests.
- Keep the agent's network off or restricted, matching the guidance in cloud coding agent internet access settings.
- Review the maintenance script as carefully as the setup script, since it runs on resumed containers.
Step by step: test it yourself
- Create a test environment with a dummy secret and a dummy environment variable, both with obviously fake values.
- In the setup script, print whether each is present, without printing the values.
- Ask the agent to report whether it can see either value, again without echoing them.
- Check whether the dummy value appears in logs or the diff.
- Run a second task within the cache window and check for leftovers, such as a file you created in setup.
- Change the setup script, run again, and see whether the change takes effect on a cached container.
- Record the results with the product version and the date.
A worked example
A team needs a token to reach a private package registry. First attempt: the token is an environment variable. The agent can see it, and a poisoned README tells the agent to print its environment into a comment. Second attempt: the token is stored as a secret and used in the setup script only. The README trick finds nothing. The team then notices the setup script also wrote the registry config, with the token, to a file in the home directory, which the agent can read. Third attempt: the script deletes that file after the install. The team repeats the test and confirms the agent sees nothing.
Each fix came from testing, not from reading the documentation, although the documentation told them where to look.
What other products do
Other products organize phases differently, and some do not split them at all. Ask each vendor three questions: which credentials exist during installation, which exist while the agent acts, and what survives between tasks. Their answers belong in your scorecard.
Questions for any vendor
Whatever the product, ask for a written answer to these: Which credentials exist during installation, and who can supply them? Are any of them still present when the agent starts acting? Can the agent read its own environment, and is that logged? What persists between tasks, for how long, and who can clear it? Can an administrator inspect an environment configuration without running a task? A vendor that has thought about phases will answer quickly. A vague answer is a reason to run the test above twice.
Try it yourself
Click through it at your own pace, or open it full screen. See how a guardrail controls which tool calls an assistant may make, and think about which credentials your own agent phase should never hold.
Where Safeguard fits
Safeguard's agent identity gives an agent its own identity and scoped access, and its MCP Guardrail and policies set limits on tool calls. Pair those with the phase separation above so the agent holds as little as it needs.
Quick check
Is a secret in the setup phase always safe?
Not if the setup script copies it somewhere the agent can read, or if it lands in a cache. Test for leftovers after setup.
Should the agent ever hold a write token?
Only a narrow one, such as a token that opens pull requests but cannot push to protected branches, and with review before merge.
How long can cached container state last?
The Codex page states up to 12 hours. Check the current documentation and your own tests, since this can change.
Sources
Last reviewed: 19 October 2026.
