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 |
Trace Log Payload Protection (0.142.5)
Codex CLI 0.142.5 prevents full Responses WebSocket request payloads from being written to trace logs. This does not change the slash-command inventory, but it matters for teams that collect local, CI, or debug traces because prompts, context, and tool inputs can be sensitive.
- Use 0.142.5 or later as the minimum install baseline for environments that retain trace logs.
- Treat old trace/debug logs as potentially sensitive and review retention or scrubbing policies.
- Keep feature runbooks tied to 0.142.0, but keep log-protection checks tied to 0.142.5 or later.
0.143.0–0.144.0 Security and Isolation
- App approval
writesallows declared read-only actions while prompting for writes; audit each app's action declarations before relying on it. - Pasted terminal control sequences are sanitized so they cannot corrupt TUI rendering or resumed history.
- Windows sandbox sessions can delete files inside writable roots and access the managed primary runtime; remove old workarounds only after regression tests.
- Responses WebSockets retain low-latency transport through system proxies/custom CAs, and long-running
codex_appssessions refresh expired authentication.
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.