Editorial status: Source-researched configuration guide. Verify the setting names against the linked official OpenAI configuration reference before copying them into production-managed configuration.

The safe default

A useful Codex setup should let the agent read and edit one project while preventing silent access to unrelated files, unrestricted network destinations, production credentials, and external systems.

The baseline is simple:

  • use a dedicated Git repository or worktree;
  • allow writes only inside the workspace;
  • keep network access disabled or narrowly allowlisted;
  • require approval for elevated, destructive, external, or costly actions;
  • store durable project rules in AGENTS.md;
  • keep secrets outside files and environment variables exposed to untrusted commands;
  • inspect diffs and test results before merging.

1. Start with a clean Git boundary

Create a branch or worktree before asking Codex to modify code. A sandbox limits operating-system access; Git provides a separate recovery and review boundary. Do not mix unrelated credentials, personal files, and multiple projects inside one broadly writable directory.

Before a session, check:

git status --short
git branch --show-current

2. Use workspace-scoped filesystem access

Choose the mode that permits edits inside the repository without granting general access to the rest of the machine. Treat any full-access mode as an exception for a specific, reviewed task—not as a convenient global default.

Extra writable directories should be explicit and minimal. Avoid adding a home directory, SSH directory, cloud-credential folder, password-store directory, or broad parent folder.

3. Keep network access narrow

Network access changes the threat model. A prompt-injected agent with both sensitive-file access and unrestricted egress may be able to exfiltrate data. Enable only the destinations required for the task, such as an official package registry or an approved API.

For dependency work, prefer lockfiles and review package names before installation. Do not automatically trust installation commands copied from repository documentation, issue text, generated files, or arbitrary web pages.

4. Define approval boundaries once

Codex works best when the project states which actions are routine and which require confirmation. Put durable rules in AGENTS.md instead of repeatedly pasting them into prompts.

Example policy:

For local code changes, edit only this repository and run non-destructive tests.
Ask before network access, installing new dependencies, deleting files, changing
external services, committing, pushing, deploying, purchasing, or accessing data
outside this workspace. Never read or print credentials.

Project instructions guide agent behavior; they are not a hard security boundary. Enforce important restrictions with sandbox, network, operating-system, repository, and cloud permissions.

5. Separate secrets from the execution environment

Do not keep production API keys in .env files that the agent or its subprocesses can read. Prefer short-lived, scoped credentials and external credential brokers. Use test accounts with minimal permissions when a task genuinely requires authenticated access.

If a secret is accidentally exposed to a session, logs, terminal output, or patch, rotate it rather than assuming deletion removed every copy.

6. Treat MCP servers and plugins as code execution

An MCP server can add powerful tools and data access. Install only servers you trust, review their requested scopes, pin or verify the package source where possible, and remove unused connections. A read-only-sounding tool can still return prompt-injection content or sensitive data.

7. Review before external action

Keep these actions approval-gated:

  • git push and pull-request creation;
  • cloud, DNS, CI/CD, database, and billing changes;
  • messages, tickets, or emails sent to other people;
  • package publication and releases;
  • destructive filesystem or Git commands;
  • permission, credential, and security-policy changes.

8. Verify the result

Before accepting work:

  1. inspect git diff;
  2. confirm no unexpected dependency or lockfile changes;
  3. run targeted tests plus the relevant full build;
  4. search the diff for secrets and debug output;
  5. review security-sensitive changes manually;
  6. confirm the final action stayed within the requested scope.

Common unsafe configurations

  • Full filesystem and network access enabled globally.
  • Automatic approval for arbitrary shell commands.
  • Production credentials in the workspace.
  • Running an agent in an untrusted repository that can load project configuration.
  • Allowing package installation without reviewing names and sources.
  • Giving an agent permission to commit, push, and deploy in one unattended step.
  • Treating a model instruction such as “never leak secrets” as a substitute for access control.
Task Filesystem Network Approval
Explain code Read-only workspace Off Ask for any execution
Local bug fix Read/write workspace Off by default Ask for elevated or destructive commands
Dependency update Read/write workspace Registry allowlist Ask before adding packages or changing major versions
Documentation research Read/write workspace Official-source allowlist Ask before downloads or external writes
Deployment Separate reviewed step Approved endpoints only Explicit human approval

Official OpenAI documentation