Security
Secure Codex usage across secrets, network access, telemetry, and auditability.
Key takeaways
- Codex security is mostly about boundaries: what it can read, execute, send to tools, and what evidence remains after the session.
- Apply controls per area: never paste or commit secrets, restrict filesystem access to intended paths, gate external network requests, and review destructive commands.
- Use read-only or restricted profiles for audits and production-adjacent tasks, and keep secret material in environment managers rather than prompts.
- Require human review for authentication, authorization, billing, and deployment changes, and prefer deterministic checks over verbal assurances.
- Watch for red flags: Codex asking to disable safeguards, code expanding permissions beyond the task, or an answer that cannot name what changed and how it was verified.
Codex security is mostly about boundaries: what it can read, what it can execute, what it can send to tools, and what evidence remains after the session.
Control Areas
| Area | Required control |
|---|---|
| Secrets | Never paste or commit credentials |
| Filesystem | Restrict access to intended workspace paths |
| Network | Gate external requests when the result affects code |
| Commands | Review destructive or production-impacting commands |
| Logs | Avoid leaking secrets through terminal output |
| Audit | Keep task, diff, command, and review evidence |
Sensitive Work Rules
- Use read-only or restricted profiles for audits and production-adjacent tasks.
- Keep secret material in environment managers, not prompts.
- Require human review for authentication, authorization, billing, and deployment changes.
- Prefer deterministic checks over verbal assurances.
Red Flags
- Codex asks to disable safeguards to continue.
- Generated code expands permissions beyond the task.
- A tool call would expose customer data or secrets to an unapproved endpoint.
- The final answer cannot name what was changed and how it was verified.