Developer data protection
OpenAI
Review secrets in the local Codex CLI
Review both the files the local Codex CLI can read and the environment its tools inherit. Read-only execution does not mean every file is unreadable, and a hidden .env file is not an access control. Current OpenAI documentation describes deny-read permission profiles and environment filtering; verify their availability and effective configuration in your installed client using only synthetic markers.
For Engineering security and Codex administrators
Two inputs can expose the same credential through different routes.
Fake inputs and an offline boolean probe. Product outcomes are untested.01
Separate file contents from process environment
A local task can obtain configuration by reading a file or through a tool process that inherits environment variables. Closing an editor tab does not remove either source. Identify which material the task needs, and avoid making unrelated credentials available to the workspace or launch environment.
Use distinct fake markers for the two questions. A file marker tests whether a read path makes content available. An environment marker tests whether a named variable reaches the tool process. Combining them into one result obscures which control needs attention.
Source context: OpenAI: Configuration reference
02
Review the current read boundary
OpenAI distinguishes sandbox permissions from approval decisions. An operation allowed by the sandbox may proceed under the selected approval policy, so “read-only” should not be interpreted as “cannot read secrets.” Inspect the effective workspace roots and the current permission model for the installed CLI.
The inert profile example selects d06-canary, extends the read-only built-in and denies only .env.canary beneath the effective workspace roots. Permission profiles are currently beta and do not compose with older sandbox_mode settings; managed requirements can further constrain them. Inspect the effective profile before testing. The exact filename avoids the platform-specific depth questions of unbounded deny globs.
| Documented key | Fixture example | Review condition |
|---|---|---|
| default_permissions | d06-canary | Must be the effective selected profile |
| permissions.d06-canary.extends | :read-only | Preserve the baseline restrictions |
| filesystem.":workspace_roots" .env.canary | deny | Only the isolated fake file |
| shell_environment_policy.filters | Fake variable = exclude | Separate fragment; preserve other filters |
Source context: OpenAI: Agent approvals and security · OpenAI: Permission profiles
03
Review what child processes receive
The separate environment-filter fragment names only AONA_D06_FAKE_INHERITED with an exclude rule. It does not enable inheritance or set values. Current docs prohibit combining filters with legacy exclude/include_only settings, so have the administrator review the actual configuration first. Keep evidence to the fake marker’s setup and boolean receipt rather than exporting environment contents.
The supplied offline probe checks only AONA_D06_FAKE_INHERITED and emits a boolean comparison with its fixed synthetic value. It never prints the variable’s contents or enumerates the environment. Run it only in the isolated fixture context if that operation is approved; do not use it to inspect a real credential.
Source context: OpenAI: Configuration reference
04
Collect separate, minimal observations
Start with the permitted file baseline. Then review the restricted fake file under the intended permission profile. Record any approval request and whether the marker was returned. Do not relax controls to obtain a successful read. A missing baseline needs investigation before the restricted-file result is useful.
For the environment check, decide whether the fake variable should be inherited before running the probe. A false result can mean the filter worked, the variable was never set or the launch context differed. Record those prerequisites. The result sheet therefore separates setup, intended policy and observation rather than labelling a boolean automatically secure.
| Input | Safe fixture | Evidence needed |
|---|---|---|
| Permitted file | allowed-marker.txt | Baseline read result |
| Restricted file | .env.canary copied from the pack | Profile, path and operation decision |
| Inherited variable | AONA_D06_FAKE_INHERITED | Parent setup and child boolean result |
| Approval | Actual isolated operation | Prompt shown and decision made |
05
Keep the conclusion local and dated
A March 2026 public report raised concern about .env reads. Current official documentation now describes deny-read controls, so the older report must not be presented as proof that modern Codex has none. Review the exact local CLI version and configuration instead.
This guide does not cover cloud setup scripts or cloud-agent secret lifecycles. It also does not establish Aona coverage of every CLI tool result. Close the review with the local tasks and configurations approved, unresolved owners and recheck triggers for upgrades or changes to launch settings.
Source context: Codex: historical .env read concern · OpenAI: Permission profiles
Put it into practice
Local Codex file and environment review
Use different synthetic markers to review file reads and inherited tool-process data.
Fake inputs and an offline boolean probe. Product outcomes are untested.
| Input | Intended rule | Observed |
|---|---|---|
| Allowed file | Define a readable baseline | Untested |
| Restricted .env canary | Define the read restriction | Untested |
| Fake inherited variable | Define whether inheritance is allowed | 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
# Local Codex synthetic secret review
No real credentials, provider calls or automatic configuration changes are included. Use a NEW isolated folder with no real repository or secrets.
File-read review
1. Copy env-canary.txt to .env.canary in this fixture folder.
2. Inspect codex-permissions.example.toml. It selects d06-canary, extends :read-only and denies exactly .env.canary under effective workspace roots. It is not an active config filename. Have the authorised administrator apply only the reviewed example through the supported test configuration mechanism, preserving managed requirements and other restrictions.
3. Current permission profiles are beta. They do not compose with sandbox_mode, --sandbox or sandbox_workspace_write; an older setting can cause the profile to be ignored. Confirm the effective selected profile and supported installed version before proceeding. Do not relax an existing policy to activate the example.
4. Establish a permitted read of allowed-marker.txt, then request a direct read of .env.canary. The intended profile outcome is denial of that fake file. Record actual behaviour in results.csv; the pack contains no observed client result.
Separate inherited-environment review
5. Use only AONA_D06_FAKE_INHERITED=NOT_A_CREDENTIAL_D06_ENV_MARKER from fake-environment.txt in the isolated test launch. Do not substitute a real value.
6. If the already approved baseline policy permits that fake variable, run the offline environment_probe.py through the intended tool process and record whether it returns true. A false baseline leaves the setup/inheritance prerequisite unresolved; do not broaden policy to force a true result.
7. Inspect codex-environment-filter.example.toml. An authorised administrator can add its single fake-variable exclusion while preserving the rest of the test policy. Current filters must not be mixed with legacy exclude/include_only settings. The fragment does not change inheritance or inject a value.
8. Repeat the same probe in a fresh applicable test launch. The intended filtered result is false. Record the effective configuration and result separately. The probe prints only a boolean and makes no network call.
The profile uses one exact relative filename, not an unbounded glob. Broader rules have platform/version considerations documented by OpenAI. These local tests do not establish cloud-agent behaviour or universal Aona coverage.
## Guide and source references
Canonical guide: https://aona.ai/resources/guides/codex-env-secrets-file-access/
Source review: 2026-09-21
- OpenAI: Agent approvals and security: https://learn.chatgpt.com/docs/agent-approvals-security
- OpenAI: Permission profiles: https://learn.chatgpt.com/docs/permissions
- OpenAI: Configuration reference: https://learn.chatgpt.com/docs/config-file/config-reference
- Codex: historical .env read concern: https://github.com/openai/codex/issues/13778
allowed-marker.txtInspect
SYNTHETIC_D06_ALLOWED_MARKER
env-canary.txtInspect
EXAMPLE_ONLY=NOT_A_CREDENTIAL_D06_FILE_MARKER
fake-environment.txtInspect
AONA_D06_FAKE_INHERITED=NOT_A_CREDENTIAL_D06_ENV_MARKER
environment_probe.pyInspect
# Offline probe for one fixed synthetic variable. Never prints its value.
import json
import os
name = "AONA_D06_FAKE_INHERITED"
expected = "NOT_A_CREDENTIAL_D06_ENV_MARKER"
print(json.dumps({"fixture": "D06", "expected_fake_marker_received": os.environ.get(name) == expected}))
results.csvInspect
client_version,os,permission_model,workspace_roots,input,parent_setup,intended_policy,approval,observed,evidence
,,,,allowed file,DEFINE,DEFINE,,UNTESTED,
,,,,restricted file,DEFINE,DEFINE,,UNTESTED,
,,,,fake inherited variable,DEFINE,DEFINE,,UNTESTED,
codex-permissions.example.tomlInspect
# INERT EXAMPLE: not loaded automatically. Isolated canary workspace only.
# Current permission profiles are beta. Do not combine with sandbox_mode,
# --sandbox or sandbox_workspace_write; respect managed requirements.
default_permissions = "d06-canary"
[permissions.d06-canary]
extends = ":read-only"
[permissions.d06-canary.filesystem.":workspace_roots"]
".env.canary" = "deny"
codex-environment-filter.example.tomlInspect
# INERT FRAGMENT: adds an exclusion for one fake variable only.
# Review and preserve existing policy. Do not combine filters with legacy
# shell_environment_policy.exclude or include_only in the same layer.
# No inheritance, value, sandbox or network setting is changed here.
[shell_environment_policy.filters]
"AONA_D06_FAKE_INHERITED" = "exclude"
Before you proceed
Keep these distinctions clear
- Calling every false probe result a success
- First establish whether the fake variable was set in the intended parent and reached the correct launch context.
- Reusing cloud assumptions locally
- Local CLI file and process-environment controls differ from hosted setup and agent phases.
Apply it to employee AI use
Bring your actual data path.
Aona can help assess supported employee endpoint prompt and file paths in a scoped local-client evaluation.
This fixture does not prove Aona intercepts every Codex CLI command or tool result. Native capabilities depend on installed release, OS, provider and transport.
Bring the local configuration record and fake-marker observations to a supported-path review.
Review your use caseFAQ
Questions for this decision
Does read-only mode stop Codex from reading .env files?
Does this guide apply a secure Codex configuration?
Will the environment probe print a real secret?
Can the same result approve Codex cloud?
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: Agent approvals and security
Separates sandbox permissions and approval policy.
vendor · checked 2026-09-21 - OpenAI: Permission profiles
Documents deny-read exact paths/globs and platform-specific considerations.
vendor · checked 2026-09-21 - OpenAI: Configuration reference
Documents shell-environment inheritance and filtering.
vendor · checked 2026-09-21 - Codex: historical .env read concern
A March 2026 practitioner concern, not a claim about current CLI capability.
practitioner · checked 2026-09-21