Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Codex Have Access to My Repository Secrets?

Not during the agent phase: Codex removes secrets before the agent starts and makes them available only to setup scripts. Environment variables persist, so a credential set as an env var is the exception that undoes the rule.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Codex runs a task in a cloud container, and the container needs credentials for the work it does before the agent starts. OpenAI distinguishes the values it treats as secrets from the values it treats as environment variables, and the two have different lifetimes inside a task. A developer who enters a key under the wrong heading changes who can read it. The answer to the title therefore depends on which of two settings a value was entered under, and the difference is easy to miss because both look like configuration. This page works from OpenAI's documentation for the Codex cloud environment and its internet access, using one record type as its example, a secret versus an env var in the same environment. The decision a team faces is which heading each key goes under, since a value entered as an environment variable stays readable to the agent once the agent phase starts, while a value entered under the other heading is removed before that phase begins. Does Claude Code Read My .env File? asks the file question of another tool. The vendor pages cited here were read on October 20, 2026, and each section says which statements come from them.

Key findings

  • OpenAI's Codex documentation describes secrets as removed before the agent phase begins and available only to setup scripts, while environment variables persist through the agent phase (OpenAI, Cloud, 2026).
  • A value entered as an environment variable is therefore visible to the agent, and a team that stores a token that way has put it where the documented protection does not apply (OpenAI, Cloud, 2026).
  • Adaptive attackers bypassed 12 published prompt injection defenses with attack success rates above 90% for most, so a value the agent can see should be assumed repeatable (Nasr et al., 2025).
  • Coder's documentation advises that agents should not be given "full permissions on behalf of a user" and should use "separate identities with limited scope" (Coder, 2026).
  • A governed environment that replaces values with consistent tokens before any model reads the screen keeps a key out of the context on rendered pages, a route a secrets setting does not touch (What Is Least Exposure?).
  • Real values resolve only at the approved destination, so a person approves the use of a key and the model never needs to hold it (What Is a Tethered Agent?).

Does Codex expose repository secrets to the agent?

Not in the agent phase, according to the documentation. Codex runs an environment in phases. A setup phase prepares the workspace, and a script in that phase can use the secrets it needs, for example to install a private dependency. Before the agent starts, the secrets are removed, so the agent runs without them.

The protection has a boundary. Environment variables persist, and the pages reviewed describe no removal for them. An agent that can run a command can print its environment, and an agent that can read a configuration can read what it refers to. A value stored as an env var is therefore as visible to the agent as any other variable.

The record type for this page is one environment holding two values, a secret and an env var, each with the same token inside, so that the only difference between them is the setting under which they were entered. The secret is available to the setup script and gone by the time the agent runs. The env var is present throughout. Does Cursor Read My .env File? shows the same shape in another tool, where the control is a list of paths. A sibling page, What Credentials Does a Coding Agent Pick Up When It Runs My Tests?, takes the env var half of this question in more detail, and this page keeps to the contrast between the two settings.

What do the vendors themselves say?

OpenAI's Codex documentation for cloud environments and internet access describes secrets that are removed before the agent phase and made available only to setup scripts, and environment variables that persist (OpenAI, Cloud, 2026). An approver for the use of a credential and a record of what the model read are absent from that page.

Coder's documentation says "LLMs and agents can be dangerous if not run with proper boundaries" and advises separate identities with limited scope whenever agents act autonomously (Coder, 2026). It governs the identity an agent runs as and does not describe where a credential is stored.

OpenAI researchers' own governance paper states that human approval "is a standard way to limit egregious failures" and that "actions that can only be reviewed after the fact should be more easily reversible" (Shavit et al., 2023). It states a design principle for agents in general and does not describe a Codex setting.

Source What it documents What the pages reviewed do not describe
Codex cloud environment docs Secrets removed before the agent phase; env vars persist An approver; what the model read
Coder best practices Separate identities with limited scope Where a credential is stored
OpenAI governance paper Human approval; reversibility A Codex setting

What can a setup script do with a secret?

Whatever the script is written to do. The documentation makes the secret available to setup scripts so that a build can authenticate to a private registry or fetch a private dependency. The script runs before the agent, and the secret is removed afterward.

The limit is what the script leaves behind. A script that writes the secret into a file, an environment variable or a configuration, or that caches a credential on disk, has moved the value out of the protected place and into one the agent can read. The pages reviewed do not describe a check for that, so a team should read its setup scripts with the question in mind, including any step that exports a variable or writes a credential file for a later command.

Value location Visible to the agent Note
Secret, used only by the setup script No, as documented Removed before the agent phase
Environment variable Yes, as documented Persists through the agent phase
Secret written to a file by the script Not described in the pages reviewed Test it

The practical reading is to keep the secret in the setup phase, use it once, and write nothing to disk that the agent could read. Can a Coding Agent Use a Credential It Cannot Read? describes how an agent can still do the work without holding the value.

Why does an environment variable undo the rule?

Because it is not removed. The documented rule applies to secrets as a category, and an env var is a different category with a different lifetime. A token placed in the second because it was convenient is not protected by the first. The error is easy to make because both settings accept the same text, and nothing in the form warns that one of them reaches the agent.

Attack research shows why the difference matters. The adaptive-attack record is blunt: 12 published prompt injection defenses were bypassed, most with success rates above 90% (Nasr et al., 2025). If an instruction hidden in a repository file tells the agent to print its environment and send the output somewhere, the agent only has to find the value, and the env var is the value it finds.

Poisoned content can also redirect an agent without any visible instruction. Researchers showed that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025). Harvard's security office lists Sensitive Data Exposure and Context and Memory Leakage among seven risk categories for AI-enabled systems (Harvard University Information Security and Data Privacy, 2026), and an env var in the agent's view touches both. The remedy is cheap: move the value to the secrets setting, confirm with a test that it no longer appears in the agent phase, and rotate it if it was ever visible there.

Where do the failures show up in practice?

In agents given more reach than the task needed. Columbia's DAPLab collected incidents in which agents deleted a production database, rebuilt a production environment and exfiltrated data from within a vendor's own infrastructure (Columbia DAPLab, 2026). The incidents involve other agents and are cited for one pattern: the damage tracked what each agent could reach, whatever it was asked to do.

The example record shows the pattern at small scale. A secret that the agent could not see did no harm in the agent phase. An env var holding the same value was available to a command, and the agent had no reason to hold it. OWASP's secrets management guidance gives the general practice of keeping credentials out of places where processes can read them freely (OWASP, 2024).

The fix is architectural. A value that is not in the agent's environment cannot be printed from it, so the strongest control is where the credential lives, and a credential scoped to the task limits the loss when one is exposed. Is It Safe to Let an AI Agent Set Up Your Cloud Environment? covers the cloud side of that choice.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this question it covers the pages. If the agent works in a browser on a console where a credential or an environment variable is shown, such as a project settings page or a hosting dashboard, the value is replaced with a placeholder before the model reads it. It does not decide whether a value is entered as a secret or an env var, which is a choice the team makes in the Codex environment. What Happens When an AI Agent Can See API Keys in a Console or Settings Page? takes up the rendered-page case.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so an env var read by a command in the agent phase is not closed by it. That is closed by storing the value as a secret, or by keeping it out of the environment altogether.

Methodology and limitations

This page rests on OpenAI's Codex documentation, Coder's documentation, an OpenAI governance paper, two further research papers, OWASP guidance, a Columbia DAPLab blog post, Harvard University guidance and existing RedactSure research pages. Sources were read between October 16, 2026 and October 20, 2026. Quoted facts are cited to the page that states them, and where a page was not fetched in full the claim is limited to what the title and summary plainly cover. The page is a reading of public documents and should be read with OpenAI's current documentation open, since Codex changes frequently.

RedactSure did not test Codex hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader, and in particular whether a setup script's output persists into the agent phase is not described. The tables are a summary of the documentation as read and not a configuration guide. The research papers concern attacks and agent governance in general and are cited for the principle only. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as a secret and an env var in one environment, and not organizations.

Determinations about whether a configuration meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own Codex environment, with a dummy value entered both ways, repeated after each release, since a change to the product, however small, would change the answer. The date on this page marks when the documents were read.

What the record shows

The documentation gives a direct answer with an exception. Secrets are removed before the agent phase and available only to setup scripts, and environment variables persist. The attack record shows why a value the agent can see should be assumed repeatable, and the incident record shows that damage follows reach. The pages reviewed do not say who approved each use of a credential or what the model read, so that record falls to the team. A team can confirm this with one Codex test: enter a dummy value once as a secret and once as an env var, run a command in the agent phase that lists the environment, and record which appeared.

Frequently asked questions

Does Codex have access to my repository secrets?

Not during the agent phase, according to OpenAI's documentation. Codex removes secrets before the agent starts and makes them available only to setup scripts. Environment variables are different: they persist, so a value stored as an env var remains visible to the agent. Test with a dummy value entered both ways, in the same environment, keep tokens that matter out of the environment variables, and repeat the test after each release because behavior can change and the two settings look alike.

What is the difference between a secret and an env var in Codex?

A secret is removed before the agent phase and is available only to setup scripts. An environment variable persists through the agent phase and is visible to commands the agent runs. The two look alike in the settings, which is the risk: a token entered as an env var because it was convenient is not covered by the documented protection for secrets, and the only reliable check is a test with a dummy value, run in the agent phase.

What can a setup script do with a secret?

It can use the secret during setup, for example to authenticate to a private registry or fetch a private dependency. The limit is what it leaves behind: a script that writes the value into a file, a variable or a cache has moved it somewhere the agent could read. The pages reviewed do not describe a check for that, so read your setup scripts with the question in mind, and test what remains in the environment after setup finishes, not only what the script prints.

What happens to a value once the agent can see it?

It becomes part of the context. From there it can be repeated in output, written to a log, included in a commit message or sent to a tool, and adaptive attacks bypassed most published defenses in research. A deployment token is rarely needed by an agent fixing a test, which is why keeping it out of the environment is the safer pattern. Rotate any value the agent could see, and move it to the secrets setting, where the documentation removes it before the agent starts.

Does a governed browser environment change this?

Only for rendered pages. If the agent works in a browser on a settings page that shows a credential or an env var, a governed environment replaces the value with a placeholder before the model reads it. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so an env var read by a command in the agent phase needs the secrets setting, and the two controls complement each other, each closing a different route.

What should a security team ask for in writing?

Ask which values are entered as secrets and which as environment variables, what the setup scripts write to disk, and who approves a consequential use of a credential. Ask what record shows what the model read. Treat anything the vendor does not document as unanswered, and ask for a dated answer that names the version, so the answer can be checked again after the next release, and a named owner for the answer.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Keeps a Console Credential Out of the Agent's Context

Codex removes credentials before the agent phase, yet env vars persist, and its controls govern where a value is stored instead of what the model reads.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent opens the settings page showing the example record's token, the string enters its context, where a hidden instruction can request it. Inside the governed environment: the page renders with KEY_001, the agent pastes KEY_001 into the credentials setting, and the real value resolves there on approval. An env var read by a command stays with Codex configuration.

RedactSure is deploying now with enterprise and government customers. Adaptive attackers bypassed 12 published defenses at rates above 90 percent for most.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

Repository credentials can be protected in the environment while a settings page still shows them. Bring a Codex task that opens a settings page and see, with test values, what the model reads there. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.