Keep secrets out of the working environment, and deny access to sensitive files. Start by combining these two measures.
Read-only mode, approvals, and training opt-outs serve different purposes. Check each one separately when deciding whether it can prevent access to secret files.
Check reading, execution, and transmission separately
Remove unnecessary secrets from the working environment. Consider a read-access deny rule for sensitive files.
Check who reviews approvals. Avoid widening the boundary through Full access or permission to run outside the sandbox.
Check command networking, transmission to the model, and browser or MCP access separately.
OpenAI's Permissions, Sandbox, approvals and security, and configuration documentation was reviewed on October 8, 2026. This guide focuses on commands inside a local sandbox. The example configuration has not been applied or tested for enforcement on a real machine. No device or account settings were changed.
Contents
- 1. Read-only mode, approvals, and training settings
- 2. Keep secrets out of the working environment
- 3. Example configuration for denying reads
- 4. .env patterns and gaps to check
- 5. What disabling command networking does and does not block
- 6. Environment variables, operating systems, and Cloud
- 7. Verify with dummy files
- FAQ
1. Read-only mode, approvals, and training settings
Preventing file changes is different from preventing file reads.
A mode that restricts writing. It does not hide the contents of readable files as secrets.
Defines where editing is allowed. It does not necessarily restrict reading to those same locations.
| Control | What it mainly governs | What it does not guarantee by itself |
|---|---|---|
| Read-only mode | Whether files can be changed | That accessible secret files will not be read |
| Approval policy | Who reviews actions that cross a boundary | A human check for every read within the allowed scope |
| File deny rules | Refusal of reads and writes at specified paths | Removal of content already pasted, or prevention of access through other tools |
| Command network restrictions | Network destinations for sandboxed commands | Blocking all traffic for models, authentication, browsers, MCP, and other services |
| Training settings | Whether processed data is used to improve models | That the data will not be processed or transmitted |
Even with on-request, commands within the permitted scope can run without additional approval. For human review, check both the approval policy and who receives the review request.
How automated AI review differs
approvals_reviewer = "auto_review" routes the relevant review to AI. It is not human review, and it does not add a review requirement to every action that was already permitted.
Source: OpenAI: approvals and sandbox boundaries. Training is covered separately in ChatGPT and Codex training settings and confidential information.
2. Keep secrets out of the working environment
A UI change may only require source code and fictional data. Production API keys, customer data, and family documents do not need to be in that same environment.
Moving files to another folder is not enough. If broad read permissions remain, those files may still be reachable.
Include only what the working copy needs
Use small inputs that reproduce the problem instead of production data.
Configuration examples should contain field names only. Check logs, backups, and history too.
Check whether other folders, the home directory, shared storage, or connected apps are reachable.
Can Git ignore rules prevent reads?
.gitignore specifies untracked files that Git should ignore. It does not remove OS read permissions. Even if a search tool normally skips a file, that does not guarantee that reading it by its explicit path will be denied. Adding an ignore rule also does not affect files that Git already tracks. Git documentation: what gitignore covers.
Instructions versus enforced access denial
Writing "do not read secrets" in AGENTS.md can provide useful working instructions. It does not create OS access restrictions by itself. Combine instructions with enforced access denial. See precautions when entering information into AI tools for examples of anonymizing inputs.
3. Example configuration for denying reads
Permission profiles are a beta feature. Check supported environments and the configuration selected in the current session before using them.
read: readingPermission to read the target
write: editingPermission to write to the target
deny: refusalDenies both reading and writing to the target
Watch for conflicts with legacy sandbox settings
Permission profiles may not be used when legacy settings remain in effect.
Check conflicting settings and administrator controls
Do not mix in legacy settings: default_permissions and [permissions] are not intended to be combined with legacy sandbox_mode or [sandbox_workspace_write]. Normally, if the loaded configuration contains sandbox_mode or startup uses --sandbox, the legacy approach is used. Administrator controls through allowed_permission_profiles are a separate condition.
The following is an illustrative configuration proposal that adds secret-file denial and human approval to the official workspace-scoped example. Do not replace your entire existing configuration with it. Check version support, organizational restrictions, and required execution paths, then test it in a dummy environment.
Where to configure it: user and project settings
~/.codex/config.toml
.codex/config.toml
These differ in scope and loading conditions. Project configuration is loaded only for trusted projects.
default_permissions = "project-private"
approval_policy = "on-request"
approvals_reviewer = "user"
[permissions.project-private]
extends = ":workspace"
[permissions.project-private.filesystem]
":root" = "deny"
":minimal" = "read"
[permissions.project-private.filesystem.":workspace_roots"]
".env" = "deny"
".env.production" = "deny"
"secrets" = "deny"
[permissions.project-private.network]
enabled = falseWhich paths does this example cover?
Applied to the current workspace and each additional workspace
.envTargeted for denial.env.productionTargeted for denialsecrets/ and its contentsTargeted for denialsubfolder/.envCheck separatelyRenamed secrets or copies in logsCheck separately:root denies reading. Exceptions include :minimal for execution and temporary directories allowed by the inherited profile.
Inherits editing access from :workspace and denies the specific paths above. This example does not catch secrets embedded in output.
Profile names, multiple workspaces, and temporary files
project-private is the name chosen for this example. :workspace_roots applies to the current workspace and additional workspaces, targeting the listed paths directly within each root. secrets targets a file or subtree with that name.
This configuration does not prevent every read outside the workspace. You also need to avoid copying secrets into temporary storage.
Source: OpenAI: Permission profile configuration, denial, and scope. This article does not report applying the example to a real machine and verifying isolation.
4. .env patterns and gaps to check
Exact names work well for secrets stored in known locations. When using patterns, remember that *.env and .env.* are different. Do not assume that the official **/*.env example also denies .env.production under the same conditions.
| Example rule | Intended target | Check separately |
|---|---|---|
.env | A file with this name directly in the workspace root | Subfolders and filenames with an added suffix |
.env.production | The production configuration file in the root | Production settings under other names or copies |
secrets | The path with this name in the root and its contents | Copies elsewhere, such as logs or backups |
**/*.env | Files ending in .env across directory levels | Suffixed filenames, scan depth, and changes after startup |
Check directory depth and files added after startup
On Linux, WSL, and native Windows, deny patterns containing unrestricted ** may require a bounded expansion before startup. The official documentation describes setting glob_scan_max_depth to at least 1, or specifying depth explicitly with patterns such as *.env, */*.env, and */*/*.env. If you use deeper directories, verify coverage to that depth.
Some enforcement paths collect matching paths before startup. Check whether files created afterward are denied on the OS, version, and execution environment you actually use. Do not treat deny patterns as a universal rule that will necessarily protect all future secrets.
Which rule wins when permissions overlap?
A more specific path rule can override a broader rule. Deny wins for the same path, but a narrow permission can also be created within a broad denial. Check additional configuration layers and inheritance from parent profiles too.
Sources: OpenAI: deny reads with paths and patterns, configuration loading order. Project .codex/config.toml is loaded only in trusted projects. Distinguish what is written in a file from what is active in the current session.
5. What disabling command networking does and does not block
Disabling command networking restricts network use by programs running inside the relevant sandbox. However, the Codex client's model and authentication requests are separate from command network controls. A command networking toggle being off does not prove that code read by Codex will not be transmitted as model context.
What command network restrictions cover
Network activity by commands, scripts, and their child processes.
Models and authentication, web search, connected apps, MCP, browser and Computer Use, and cloud tasks.
To allow networking while restricting destinations, you need to enable the network proxy as well as define domain rules. Listing allowed domains in a profile alone does not activate those rules.
| Command networking | Proxy | Result |
|---|---|---|
| Off | Either setting | Command networking is not allowed |
| On | Off | Direct networking is possible; profile domain rules do not apply |
| On | On | The proxy enforces domain rules and denies external destinations if none are allowed |
Secrets can still be sent to an allowed destination. Restricting domains is not the same as inspecting the content being sent. When approving execution outside the sandbox, do not assume the current denial rules still protect you unchanged. Check what that approval expands. OpenAI: network permissions and proxy requirements.
6. Environment variables, operating systems, and Cloud
Secrets are not limited to files. If the shell contains an API key, a child process may use its value through inherited environment variables even when file access is denied. Environment inheritance is managed separately with shell_environment_policy.
Automatic variable exclusions: true versus false
true | DefaultDoes not apply automatic exclusion of variables whose names contain KEY, SECRET, or TOKEN
falseApplies that automatic exclusion
ignore_default_excludes. It is separate from file deny rules and filters by variable name; it does not detect every secret.This does not protect variables under other names or values that programs retrieve from elsewhere. set is applied after exclusion and can restore excluded variables. OpenAI: environment inheritance and precedence.
Windows: check the sandbox implementation too
Local Permission profiles are documented for macOS, Linux, WSL, and native Windows, but their implementations differ. On Windows, the elevated sandbox is described as the stronger approach. The unelevated sandbox provides weaker network isolation and cannot enforce some read and write isolation policies. Unsupported policies are described as causing execution to be refused. An error is not a reason to switch to Full access. OpenAI: enforcement by operating system.
Cloud: do not reuse local settings unchanged
Check the settings for the specific Codex Cloud environment separately. Do not assume local profiles automatically apply throughout Cloud or to dot's cloud environment. Do not reuse this article's local configuration proposal unchanged as a cloud configuration. See Codex Remote, Cloud, and PC connection requirements for differences between execution locations.
7. Verify with dummy files
"I instructed it not to read," "I saved the configuration," and "the read was actually denied" are different kinds of evidence. There is no need to test by having Codex read real secrets. The following is a verification plan for the user or administrator, not a report of testing on this device.
- Record the environment: Note the Codex version, OS, execution location, and selected permissions. In the CLI, check the workspace scope with
/statusand the selected permissions with/permissions. - Check for configuration conflicts: Review user settings, trusted-project settings, the selected profile, startup flags, and administrator restrictions. Do not paste entire configuration files or secret values into the conversation for diagnosis.
- Prepare dummy files: In a separate workspace without secrets, create files intended to be allowed and denied. Use fictional markers as their contents.
- Verify both allowance and denial: Through the same execution path, confirm that allowed files can be read and denied reads produce an error. Codex voluntarily choosing not to read a file is not evidence of enforced denial.
- Test different locations: Check dummy files in the root, subfolders, suffixed filenames, and files created after startup. Do not approve an action that bypasses denial. If an unexpected read succeeds, stop using that environment and investigate.
- Check output paths too: Check whether tests or builds print secrets to logs, or pass the same information to other MCP tools, browsers, or connected apps.
Available information varies by CLI version and display, so check the actual output rather than relying on command names. The official CLI also provides OS-specific checks through codex sandbox. Before treating them as equivalent, verify that the settings tested with a helper command match those active in your usual desktop or IDE session. OpenAI: testing the sandbox.
Adding deny rules later cannot undo content already read. Check storage of past conversations, logs, and files, along with training settings, separately. A successful file read alone does not establish disclosure to a third party. Assess what was read, where it went, and whether credentials need attention as separate questions.
Users have also requested ways to exclude secret files in a public Codex issue. This illustrates a real concern; it does not prove that the feature is unsupported today. This article bases its specification claims on the current official Permissions documentation rather than older posts.
FAQ
Does read-only mode prevent .env from being sent?
No such guarantee follows from read-only mode: it restricts changes. To prevent readable .env contents from becoming model context, separately check read denial for the file and a working environment that contains no secrets.
Are .gitignore or AGENTS.md enough?
They do not replace enforced denial of reads. Git ignore rules, working instructions, and OS-enforced permissions are separate mechanisms. Verify with dummy files that deny works in the current execution environment.
Does disabling networking make Codex run entirely on the device?
No. Command network restrictions do not disable communication with models or authentication services. Browser, MCP, connected-app, and cloud settings are separate too.
Does this example completely protect secrets on Windows?
Complete protection is not guaranteed. You need to check beta feature support, the OS sandbox implementation, actual configuration layers, paths, and tools being run. This article's example has not been applied or tested on a real machine.
