Codex: Codex Permission Settings
Last updated: 2026-08-31
Codex has powerful operational capabilities, but they also bring security risks. This lesson covers permission settings in detail, ensuring AI operations remain under your control.
📋 Prerequisites: Basic Codex configuration knowledge (see Lesson 6)
1. What You Will Learn
- Permission model hierarchy
- Three sandbox modes in detail
- Approval policy configuration
- Sensitive operation protection
2. Permission Model
(1) Operation Permission Hierarchy
| Permission Level | Scope | Default Behavior |
|---|---|---|
| Read | Read project files | Auto-allowed |
| Write | Modify/create project files | Requires confirmation (configurable) |
| Execute | Run shell commands | Requires confirmation |
| Network | Install packages, access APIs | Requires confirmation |
| System | Access sensitive directories | Requires confirmation |
(2) Risk Levels
| Level | Example Operations | Protection |
|---|---|---|
| 🟢 Low | Read source code files | Auto-allowed |
| 🟡 Medium | Modify source code files | Requires confirmation |
| 🟠 High | Execute shell commands | Requires confirmation + show command |
| 🔴 Critical | Delete files, access keys | Requires confirmation + extra warning |
3. Sandbox Modes in Detail
(1) Read-only
BASH
codex --sandbox readonly
| Capability | Status |
|---|---|
| Read files | ✅ |
| Modify files | ❌ |
| Execute commands | ❌ |
| Network access | ❌ |
Use for: Code review, architecture analysis, documentation generation
(2) Workspace-write
BASH
codex --sandbox workspace-write
| Capability | Status |
|---|---|
| Read files | ✅ |
| Modify workspace files | ✅ |
| Execute commands | ⚠️ Requires confirmation |
| Network access | ❌ |
Use for: Daily development (default mode)
(3) Full-access
BASH
codex --sandbox full-access
| Capability | Status |
|---|---|
| Read files | ✅ |
| Modify any file | ✅ |
| Execute commands | ✅ |
| Network access | ✅ |
Use for: Fully trusted automation scenarios (use with caution)
▶ Example 1: Alice Chooses Mode by Scenario
PYTHON
def choose_sandbox(task_type):
modes = {
"code_review": "readonly",
"daily_dev": "workspace-write",
"full_migrate": "full-access",
}
return modes.get(task_type, "workspace-write")
# Alice's work today
print(choose_sandbox("code_review")) # readonly
print(choose_sandbox("daily_dev")) # workspace-write
print(choose_sandbox("full_migrate")) # full-access
4. Approval Policies
(1) Three Policies
| Policy | Behavior | Risk |
|---|---|---|
ask |
Prompt user each time | Safest |
approve |
Auto-approve | Moderate risk |
deny |
Auto-deny | Most conservative |
(2) Per-Operation-Type Configuration
TOML
# ~/.codex/config.toml
[approval]
# Shell command approval
shell_commands = "ask"
# File write approval
file_writes = "ask"
# Network access approval
network_access = "deny"
# Sensitive path approval
sensitive_paths = "ask"
(3) Command Allowlist
TOML
[approval]
shell_commands = "ask"
# Auto-approved safe commands
auto_approve_commands = [
"git status",
"git diff",
"npm test",
"pytest",
"ls",
"cat",
]
# Always-denied dangerous commands
always_deny_commands = [
"rm -rf",
"sudo",
"chmod 777",
"curl * | sh",
]
5. Sensitive Path Protection
(1) Default Protected Paths
TEXT
📖 Display only
~/.ssh/
~/.gnupg/
/etc/
.env
.env.*
secrets/
credentials/
*.key
*.pem
(2) Custom Protected Paths
TOML
[sandbox]
blocked_paths = [
".env",
".env.production",
"secrets/",
"credentials/",
"config/production.yml",
"*.key",
"*.pem",
]
▶ Example 2: Bob Protects Production Config
TOML
# Bob's project sandbox config
[sandbox]
mode = "workspace-write"
allowed_paths = ["src/", "tests/", "docs/"]
blocked_paths = [
".env.production",
"config/prod/",
"secrets/",
"deploy/",
]
6. Permission Auditing
(1) View Operation Logs
BASH
# View all operations in the current session
codex --audit-log
# Output example
[10:30:15] READ src/auth.ts (auto-approved)
[10:30:18] WRITE src/auth.ts (approved by user)
[10:30:22] SHELL npm test (approved by user)
[10:30:25] WRITE test/auth.test.ts (approved by user)
(2) Audit Configuration
TOML
[audit]
log_all_operations = true
log_file = "~/.codex/audit.log"
include_shell_output = true
7. Best Practices
| Practice | Description |
|---|---|
| Default to ask policy | Don't casually switch to approve |
| Limit sandbox scope | Only open necessary paths |
| Protect key files | Add .env and keys to blocked_paths |
| Regularly review logs | Check what Codex has executed |
| Git as safety net | Commit before letting Codex modify — easy rollback |
| Use deny in CI | Reject all write operations in continuous integration |
❓ FAQ
Q What are the risks of Full-access mode?
A Codex can execute any command, modify any file, and access the network. If Codex misjudges, it may delete important files or execute dangerous commands. Use only in fully trusted scenarios.
Q Can I switch approval policies at runtime?
A Yes. During a Codex session, enter
/mode to switch modes, or tell Codex "from now on, all operations need my confirmation."Q How do I prevent Codex from accessing .env files?
A Add
.env and .env.* to blocked_paths in your config, and use workspace-write mode.Q Will Codex secretly execute commands?
A Not in ask mode — all sensitive operations require confirmation first. But in approve or Full Auto mode, Codex will auto-execute.
Q How do I know what Codex did?
A Enable audit logging, or use
git diff to view code changes. Codex also displays all operations in real time in the conversation window.📖 Summary
- Permission hierarchy: Read → Write → Execute → Network → System
- Three sandbox modes: readonly / workspace-write / full-access
- Approval policies: ask (safe) / approve (auto) / deny (conservative)
- Protect sensitive paths: .env, keys, production configs
- Best practices: default ask + Git safety net + audit logging
📝 Exercises
- Basic (⭐): Configure workspace-write sandbox mode and protect .env files.
- Intermediate (⭐⭐): Configure a command allowlist — auto-approve test commands, deny dangerous ones.
- Advanced (⭐⭐⭐): Design an enterprise-grade permission scheme — different roles with different permissions — and write a permission matrix document.
