# Codex Permissions, sandbox and security

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

URL: https://docs.passion8.cc/en/docs/codex/permissions-sandboxing
Language: en
Publisher: Passion8

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 |

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

```toml title="~/.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:

```toml title="~/.codex/config.toml"
[sandbox_workspace_write]
network_access = true
```

For supported network-proxy domain policy:

```toml
[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:

```toml
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:

```toml
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.

```python title="~/.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:

```bash
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:

```toml
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

- [Configuration reference](https://developers.openai.com/codex/config-reference)
- [Codex manual: approvals and security](https://developers.openai.com/codex/codex-manual.md)
- [Codex manual: sandbox and permissions](https://developers.openai.com/codex/codex-manual.md)
- [Codex manual: rules](https://developers.openai.com/codex/codex-manual.md)