ความปลอดภัยการอนุมัติ Agent

Agent Approvals & Security

จัดการว่า Codex ต้องขออนุมัติก่อนทำอะไร และตั้งค่า Security Policy

How to securely operate Codex with sandboxing, approvals, and network controls

Codex helps protect your code and data and reduces the risk of misuse.

This page covers how to operate Codex safely, including sandboxing, approvals, and network access. If you are looking for Codex Security, the product for scanning connected GitHub repositories, see Codex Security.

By default, the agent runs with network access turned off. Locally, Codex uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace), plus an approval policy that controls when it must stop and ask you before acting.

For a high-level explanation of how sandboxing works across the Codex app, IDE extension, and CLI, see sandboxing. For a broader enterprise security overview, see the Codex security white paper.

Sandbox and approvals

Codex security controls come from two layers that work together:

Sandbox mode: What Codex can do technically (for example, where it can write and whether it can reach the network) when it executes model-generated commands.

Approval policy: When Codex must ask you before it executes an action (for example, leaving the sandbox, using the network, or running commands outside a trusted set).

Codex uses different sandbox modes depending on where you run it:

Codex cloud: Runs in isolated OpenAI-managed containers, preventing access to your host system or unrelated data. Uses a two-phase runtime model: setup runs before the agent phase and can access the network to install specified dependencies, then the agent phase runs offline by default unless you enable internet access for that environment. Secrets configured for cloud environments are available only during setup and are removed before the agent phase starts.

Codex CLI / IDE extension: OS-level mechanisms enforce sandbox policies. Defaults include no network access and write permissions limited to the active workspace. You can configure the sandbox, approval policy, and network settings based on your risk tolerance.

In the Auto preset (for example, --sandbox workspace-write --ask-for-approval on-request), Codex can read files, make edits, and run commands in the working directory automatically.

Codex asks for approval to edit files outside the workspace or to run commands that require network access. If you want to chat or plan without making changes, switch to read-only mode with the /permissions command.

Codex can also elicit approval for app (connector) tool calls that advertise side effects, even when the action isn’t a shell command or file change. Destructive app/MCP tool calls always require approval when the tool advertises a destructive annotation, even if it also advertises other hints (for example, read-only hints).

Network access Elevated Risk

For Codex cloud, see agent internet access to enable full internet access or a domain allow list.

For the Codex app, CLI, or IDE Extension, the default workspace-write sandbox mode keeps network access turned off unless you enable it in your configuration:

[sandbox_workspace_write] network_access = true Network isolation Network access is controlled through destination rules that apply to scripts, programs, and subprocesses spawned by commands. When command network access is already enabled, turn on the network_proxy feature to constrain that traffic to the network policy you configure.

[features.network_proxy] enabled = true domains = { "api.openai.com" = "allow", "example.com" = "deny" } For a one-off CLI session, use the boolean shorthand when you only need the toggle, and the table form when you also set policy options:

codex \ -c 'features.network_proxy=true' \ -c 'sandbox_workspace_write.network_access=true' codex \ -c 'features.network_proxy.enabled=true' \ -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \ -c 'sandbox_workspace_write.network_access=true' The feature changes how enabled network access is enforced; it does not grant network access by itself. Use sandbox_workspace_write.network_access with workspace-write config to decide whether commands have network access at all:

Network off + network_proxy on: network stays off, and the feature does nothing.

Network on + network_proxy off: network stays on with unrestricted direct outbound access.

Network on + network_proxy on: network stays on, and outbound traffic is constrained by the configured network policy.

Admin-managed experimental_network requirements are separate from the user feature toggle. They can configure and start sandboxed networking without features.network_proxy, but they do not turn on network access when the active sandbox keeps it off. See Managed configuration for the administrator-side requirements.toml shape.

Network policy

Domain rules are allowlist-first:

Exact hosts match only themselves.

*.example.com matches subdomains such as api.example.com, but not example.com.

**.example.com matches both the apex and subdomains.

A global * allow rule matches any public host that is not denied. Treat * as broad network access and prefer scoped rules when you can.

deny always wins over allow, and global * is only valid for allow rules.

Local and private destinations

By default, allow_local_binding = false blocks loopback, link-local, and private destinations:

Specific exceptions: add an exact local IP literal or localhost allow rule when a command needs one local target.

Broader access: set allow_local_binding = true only when you intentionally want wider local/private reach.

Wildcards: wildcard rules do not count as explicit local exceptions.

Resolved addresses: hostnames that resolve to local/private IPs stay blocked even if they match the allowlist.

DNS rebinding protections

Before allowing a hostname, Codex performs a best-effort DNS and IP classification check:

Lookups that fail or time out are blocked.

Hostnames that resolve to non-public addresses are blocked.

The check reduces DNS rebinding risk, but it does not eliminate it. Preventing rebinding completely would require pinning resolved IPs through the transport layer.

If hostile DNS is in scope, enforce egress controls at a lower layer too.

Dangerous settings

Two settings deliberately widen the trust boundary:

dangerously_allow_non_loopback_proxy = true can expose proxy listeners beyond loopback.

dangerously_allow_all_unix_sockets = true bypasses the Unix socket allowlist.

Use them only in tightly controlled environments. When Unix socket proxying is enabled, listeners stay loopback-only even if non-loopback binding was requested, so sandboxed networking does not become a remote bridge into local daemons.

network_proxy is off by default. When you enable it:

Setting

Default

Behavior

enabled

false

Starts sandboxed networking only when command network access is already on.

domains

unset

Uses allowlist behavior, so no external destinations are allowed until you add allow rules. Supports exact hosts, scoped wildcards, and global * allow rules; deny always wins.

unix_sockets

unset

No Unix socket destinations are allowed until you add explicit allow rules.

allow_local_binding

false

Blocks local and private-network destinations unless you add an exact local IP literal or localhost allow rule, or explicitly opt into broader local/private access.

enable_socks5

true

Exposes SOCKS5 support when policy allows it.

enable_socks5_udp

true

Allows UDP over SOCKS5 when SOCKS5 is available.

allow_upstream_proxy

true

Lets sandboxed networking honor an upstream proxy from the environment.

dangerously_allow_non_loopback_proxy

false

Keeps listener endpoints on loopback unless you deliberately expose them beyond localhost.

dangerously_allow_all_unix_sockets

false