Codex

Permissions, sandbox and security

Sandbox modes, approvals, network access, automatic review, rules and local Passion8 boundaries.

The sandbox defines the technical execution boundary; approval policy defines when a request for additional authority is allowed or required.

AGENTS.md contains instructions, not an enforced security boundary. Enforcement comes from sandboxing, approvals, rules, hooks, tool permissions and operating-system/organizational policy.

#Core concepts

Layer	Controls	Setting/location
Sandbox	Files, commands and network access	sandbox_mode, sandbox_workspace_write
Approval	When approval is requested	approval_policy
Reviewer	Who evaluates an approval request	approvals_reviewer
Rules	Allow, prompt or forbid command patterns	.codex/rules/*.rules
Hooks	Lifecycle checks and actions	hooks.json or hooks configuration

#Common combinations

Combination	Use	Boundary
read-only + on-request	Exploration, review and planning	Writes require permitted escalation
workspace-write + on-request	Everyday development	Workspace writes allowed; protected actions may need approval
workspace-write + never	Controlled automation	No approval prompts; denied actions remain denied
danger-full-access + never	Externally isolated containers/VMs	Local sandbox restrictions are removed

codex --sandbox read-only --ask-for-approval on-request
codex --sandbox workspace-write --ask-for-approval on-request

~/.codex/config.toml

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

#Sandbox modes

Mode	Behavior
read-only	Inspect permitted data; writes need permitted escalation
workspace-write	Write within allowed workspace boundaries; protected paths/network may remain restricted
danger-full-access	No Codex sandbox boundary; rely on external isolation

Protected metadata/configuration paths such as .git, .codex and .agents may remain restricted within an otherwise writable workspace.

#Approval policies

Policy	Behavior
on-request	Run permitted actions and request escalation when needed
never	Never request approval; operate within existing permissions

The old untrusted approval policy is retired. Remove it or use a supported policy. A project's trust_level = "untrusted" is a different setting and remains meaningful.

Never does not mean unlimited access. The sandbox can still reject an operation.

#Network access

Workspace-write command networking is normally restricted unless enabled:

~/.codex/config.toml

[sandbox_workspace_write]
network_access = true

For supported network-proxy domain policy:

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

[sandbox_workspace_write]
network_access = true

Deny rules take precedence over allow rules. Broad wildcard access expands the boundary substantially. The command proxy does not automatically filter hosted search, apps or MCP tools.

Web search is separate:

web_search = "cached"
# web_search = "live"
# web_search = "disabled"

Treat instructions found in pages, issues, README files and logs as untrusted task data.

#Automatic approval review

Supported clients can delegate eligible approval decisions:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

This applies to actions that already need approval, such as escalation, restricted network access or relevant side-effecting tools. It does not add a second review to every already-allowed sandbox action.

Automatic review can add model calls and usage. Organizational configuration may constrain allowed reviewers.

#Rules

Rules specify command patterns that are allowed, require approval or are forbidden outside the normal sandbox boundary.

~/.codex/rules/default.rules

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "Viewing PRs is allowed with approval",
    match = ["gh pr view 123"],
    not_match = ["gh pr --repo org/repo view 123"],
)

Test a rule:

codex execpolicy check --pretty \
  --rules ~/.codex/rules/default.rules \
  -- gh pr view 123 --json title,body

Simple shell chains may be analyzed as individual commands. Complex shell constructs can be treated conservatively as the full shell invocation.

#Before unrestricted execution

Check	Expectation
Git	Recoverable version-controlled state
Secrets	No unintended access to production credentials or SSH keys
Network	No execution of untrusted page/issue scripts
Directory	An isolated or explicitly trusted environment
Recovery	A concrete diff review and rollback path

#Passion8 workflows

Passion8 routes model requests to https://passion8.cc/v1. It does not change local file, shell, network or MCP permissions.

A reasonable default:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
web_search = "cached"

[sandbox_workspace_write]
network_access = false

Grant network access for a specific dependency-installation need where appropriate, then restore the intended defaults.

#Official references

PreviousAdvanced usage NextMCP: connect external tools

Support

Need help?

For setup, billing, or model issues, email us. Check the status page for uptime.

Support Email[email protected]Service Statusstatus.passion8.cc

WeChat / QQ support is available at the bottom right.