在OpenAI安全运行Codex

As AI systems become more capable, they increasingly act on behalf of users. Coding agents can autonomously review repositories, run commands, and interact with development tools. These are tasks that previously required direct human execution.

With Codex, we’ve designed these capabilities alongside the controls organizations need for safe deployment. Security teams need ways to govern how agents operate: what they can access, when human approval is required, which systems they can interact with, and what telemetry exists to explain their behavior.

At OpenAI, we deploy Codex with a few clear goals: keep the agent inside clear technical boundaries, let developers move quickly on low-risk actions, and make higher-risk actions explicit. We also preserve agent-native telemetry so we can understand and audit what the agent did. In practice, that means managed configuration, constrained execution, network policies, and agent-native logs.

Controlling how Codex operates

We deploy Codex with a simple principle that it should be productive inside a bounded environment, low-risk everyday actions should be frictionless, and higher-risk actions should stop for review.

Approvals and sandboxing work together. The sandbox defines the technical execution boundary, including where Codex can write, whether it can reach the network, and which paths remain protected. Approval policy determines when Codex must ask to perform an action, such as when it needs to do something outside of the sandbox. Users can approve the action once, or approve that type of action for that session.

For routine approval requests, we are using Auto-review mode, which is a feature that, when turned on, auto-approves certain kinds of requests to reduce how often users have to stop and approve Codex actions. Codex sends the planned action and recent context to the auto-approval subagent, which can automatically approve low-risk actions instead of interrupting the user. That keeps Codex moving on routine work while still stopping on higher-risk or actions with unintended consequences.

We do not run Codex with open-ended outbound access. Our managed network policy allows expected destinations, blocks destinations we do not want Codex reaching, and requires approval for unfamiliar domains. That lets Codex complete common, known-good workflows without giving it broad network access.

We also manage how Codex authenticates. CLI and MCP OAuth credentials are stored in the secure OS keyring, login is forced through ChatGPT, and access is pinned to our ChatGPT enterprise workspace. That keeps Codex usage tied to our workspace-level controls and makes Codex activity available in the ChatGPT Compliance Logs Platform for our enterprise workspace.

We use rules so Codex does not treat every shell command as equally safe. Common benign commands that engineers use in day-to-day development are allowed without approval outside of the sandbox and specific dangerous commands can be blocked or require approval. That lets Codex move quickly through ordinary engineering tasks while still forcing review or blocking patterns we do not want to run outside the sandbox.

We apply this posture through a combination of cloud-managed requirements, macOS managed preferences, and local requirements files. Requirements are admin-enforced controls that users cannot override. The macOS managed preferences and local requirements files allow us to keep a consistent baseline while still testing different configurations by team, user group, or environment. These configurations apply across local Codex surfaces, including the desktop app, CLI, and IDE extension.

Agent-native telemetry and audit trails

Control is only half the job. Once agents are deployed, security teams need visibility into what these agents are doing and why. Traditional security logs are still useful when looking at actions taken by Codex, but they mostly answer what happened: a process started, a file changed, a network connection was attempted. Defenders are still left to figure out why Codex did something, or the user's intent.

Codex can give security teams a more agent-aware view. Codex supports OpenTelemetry log export for various Codex events such as user prompts, tool approval decisions, tool execution results, MCP server usage, and network proxy allow or deny events. Codex activity logs are also available through the OpenAI Compliance Platform for Enterprise and Edu customers.

At OpenAI, we use Codex logs alongside our AI-powered security triage agent. When an endpoint alert says Codex did something unusual, the endpoint security tool tells us that a suspicious event occurred. Codex logs then help explain the surrounding intent by the user and agent. Our AI security triage agent uses Codex logs to inspect the original request, tool activity, approval decisions, tool results, and any relevant network policy decision or block. The AI security triage agent surfaces its analysis to our security team for review to distinguish between expected agent behavior, benign mistakes, and activity that truly warrants escalation.

We also use the same telemetry operationally. We use these logs to understand how internal adoption is changing, which tools and MCP servers are being used, how often the network sandbox is blocking or prompting, and where the rollout still needs tuning. These OpenTelemetry logs can be centralized in SIEM and compliance logging systems.

Looking ahead

As coding agents like Codex become integrated into development workflows, security teams need tools specifically designed for managing this shift. Codex provides the control surfaces, configuration management, sandboxing, and detailed agent-aware telemetry needed to ensure safe adoption. With those capabilities in place, security teams can enable Codex with greater confidence, balancing developer productivity with the visibility and control required for enterprise security. More information on configuring Codex can be found here⁠(opens in a new window), and the Compliance API here⁠(opens in a new window).

链接抓取：https://developers.openai.com/codex/config-basic

Codex reads configuration details from more than one location. Your personal defaults live in ~/.codex/config.toml

, and you can add project overrides with .codex/config.toml

files. For security, Codex loads project .codex/

layers only when you trust the project.

Codex configuration file

Codex stores user-level configuration at ~/.codex/config.toml

. To scope settings to a specific project or subfolder, add a .codex/config.toml

file in your repo.

To open the configuration file from the Codex IDE extension, select the gear icon in the top-right corner, then select Codex Settings > Open config.toml.

The CLI and IDE extension share the same configuration layers. You can use them to:

• Set the default model and provider.
• Configure
  approval policies and sandbox settings. - Configure
  MCP servers.

Configuration precedence

Codex resolves values in this order (highest precedence first):

• CLI flags and
  --config

overrides Profilevalues (from--profile <name>

)- Project config files:
.codex/config.toml

, ordered from the project root down to your current working directory (closest wins; trusted projects only) - User config:
~/.codex/config.toml

• System config (if present):
  /etc/codex/config.toml

on Unix - Built-in defaults

Use that precedence to set shared defaults at the top level and keep profiles focused on the values that differ.

If you mark a project as untrusted, Codex skips project-scoped .codex/

layers, including project-local config, hooks, and rules. User and system config still load, including user/global hooks and rules.

For one-off overrides via -c

/--config

(including TOML quoting rules), see Advanced Config.

On managed machines, your organization may also enforce constraints via
requirements.toml

(for example, disallowing approval_policy = "never"

or
sandbox_mode = "danger-full-access"

). See Managed
configuration and Admin-enforced
requirements.

Common configuration options

Here are a few options people change most often:

Default model

Choose the model Codex uses by default in the CLI and IDE.

model = "gpt-5.5"

Approval prompts

Control when Codex pauses to ask before running generated commands.

approval_policy = "on-request"

For behavior differences between untrusted

, on-request

, and never

, see Run without approval prompts and Common sandbox and approval combinations.

Sandbox level

Adjust how much filesystem and network access Codex has while executing commands.

sandbox_mode = "workspace-write"

For mode-by-mode behavior (including protected .git

/.codex

paths and network defaults), see Sandbox and approvals, Protected paths in writable roots, and Network access.

Permission profiles

Use a named permission profile when you want one reusable filesystem or network policy across sessions:

default_permissions = ":workspace"

Built-in profiles include :read-only

, :workspace

, and :danger-no-sandbox

. For custom filesystem or network rules, define [permissions.<name>]

tables and set default_permissions

to that name.

Windows sandbox mode

When running Codex natively on Windows, set the native sandbox mode to elevated

in the windows

table. Use unelevated

only if you don’t have administrator permissions or if elevated setup fails.

[windows]
sandbox = "elevated" # Recommended

sandbox = "unelevated" # Fallback if admin permissions/setup are unavailable

Web search mode

Codex enables web search by default for local tasks and serves results from a web search cache. The cache is an OpenAI-maintained index of web results, so cached mode returns pre-indexed results instead of fetching live pages. This reduces exposure to prompt injection from arbitrary live content, but you should still treat web results as untrusted. If you are using --yolo

or another full access sandbox setting, web search defaults to live results. Choose a mode with web_search

:

"cached"

(default) serves results from the web search cache."live"

fetches the most recent data from the web (same as--search

)."disabled"

turns off the web search tool.

web_search = "cached" # default; serves results from the web search cache

web_search = "live" # fetch the most recent data from the web (same as --search)

web_search = "disabled"

Reasoning effort

Tune how much reasoning effort the model applies when supported.

model_reasoning_effort = "high"

Communication style

Set a default communication style for supported models.

personality = "friendly" # or "pragmatic" or "none"

You can override this later in an active session with /personality

or per thread/turn when using the app-server APIs.

TUI keymap

Customize terminal shortcuts under tui.keymap

. Context-specific bindings override tui.keymap.global

, and an empty list unbinds the action.

[tui.keymap.global]
open_transcript = "ctrl-t"
[tui.keymap.composer]
submit = ["enter", "ctrl-m"]

Command environment

Control which environment variables Codex forwards to spawned commands.

[shell_environment_policy]
include_only = ["PATH", "HOME"]

Log directory

Override where Codex writes local log files such as codex-tui.log

.

log_dir = "/absolute/path/to/codex-logs"

For one-off runs, you can also set it from the CLI:

codex -c log_dir=./.codex-log

Feature flags

Use the [features]

table in config.toml

to toggle optional and experimental capabilities.

[features]
shell_snapshot = true # Speed up repeated commands

Supported features

multi_agent

personality

shell_snapshot

shell_tool

shell

toolunified_exec

true

except Windowsundo

web_search

settingweb_search_cached

web_search = "cached"

when unsetweb_search_request

web_search = "live"

when unsetThe Maturity column uses feature maturity labels such as Experimental, Beta,
and Stable. See Feature Maturity for how to
interpret these labels.

For the current lifecycle hooks MVP, see Hooks.

Enabling features

• In
  config.toml

, addfeature_name = true

under[features]

. - From the CLI, run
codex --enable feature_name

. - To enable more than one feature, run
codex --enable feature_a --enable feature_b

. - To disable a feature, set the key to
false

inconfig.toml

链接抓取：https://help.openai.com/en/articles/9261474-openai-compliance-platform-for-enterprise-and-edu-customers

Obtain audit and compliance data in your workspace.

Compliance API documentation

How to get access

The Compliance Platform is available to Enterprise and Edu customers. If you'd like to purchase a plan for your organization, pleasereach out to our sales team or your account manager.

How it works

The Compliance Platform provides access to logs and metadata from your ChatGPT workspace that you can connect with your eDiscovery, DLP, or SIEM tools.

The Compliance Platform supports two complementary access patterns:

• Compliance Logs Platform for immutable, append-only compliance log events for auditing purposes.

• Stateful Compliance API for querying state at the time of request. These are useful for joining data referenced from events above and for legacy data types for audit purposes.

You can use the API Documentation and quickstart notebook to learn how to ingest data into your SIEM or data lake.

eDiscovery tools help in identifying, collecting, and delivering electronic information that can be used as evidence in legal cases.

• Organizations use these tools during litigation, investigations, or audits. They enable legal teams to sift through large volumes of data to find relevant documents and communications efficiently.

DLP (Data Loss Prevention) tools are used to detect and prevent data breaches, data exfiltration, and the unauthorized use or access to sensitive information within an organization.

• They are commonly used to protect intellectual property and ensure compliance with privacy laws and regulations such as GDPR, HIPAA, etc. DLP systems monitor, detect, and block sensitive data while in-use (endpoint actions), in-motion (network traffic), and at-rest (data storage).

SIEM (Security Information and Event Management) tools provide real-time analysis of security alerts generated by applications and network hardware.

• They are used for threat detection, security incident management, and compliance. By aggregating and analyzing log data, SIEM systems help identify anomalous behavior and potential threats.

Data Retention with the Compliance API

The Compliance Logs Platform retains data for 30 days. If longer retention is desired then consumers should implement a system to continuously download all logs and retain them according to their policies.

Deleted data is not recoverable. This API does not provide the capability for deleting any data logged internally specifically for audit or security within OpenAI. All authenticated requests to this API are logged for security and compliance purposes. When an item is deleted using this API, it is also removed from all production search and retrieval indexes. Data is retained internally for no greater than 30 days following a deletion request.

Deprecation Notice

On March 5th, 2026a new conversations logs system was released, deprecating the old stateful route.

Action May Be Required: the stateful route will be removed June 5th, 2026. Please follow the API Documentation to move your integrations to the new source as soon as possible.

Partner Integrations

To help with their compliance requirements, customers can take advantage of 13 Compliance API integrations built by leading eDiscovery and Data Loss Prevention (DLP) companies.

Updated conversation message logs in the Logs Platform are currently supported by:

• CrowdStrike

• Global Relay

• Teleskope

• Zenity

And implementations are in progress by:

• Apex Security

• Concentric AI

• Forcepoint

• Microsoft Purview

• Netskope

• Palo Alto Networks

• Relativity

• Smarsh

• TrojAI

• Varonis

• Zscaler

All partners support ingestion of the other data types. You can read more about the Compliance API in ourblog post.

Partner Setup Guides

Microsoft

• Microsoft Purview: Use Microsoft Purview to manage data security & compliance for ChatGPT Enterprise

• Microsoft Purview: Unlocking the Power of Microsoft Purview for ChatGPT Enterprise (blog)

Netskope

• Netskope: Configure ChatGPT Enterprise for the Next Generation API Data Protection

• Netskope: Netskope + ChatGPT Enterprise Compliance API

• Netskope Community: Demo – Configure ChatGPT Enterprise Compliance API

Palo Alto Networks

• Begin Scanning ChatGPT Enterprise App

Relativity

• Relativity: ChatGPT Enterprise data source

Apex Security

• Tenable AI Exposure: ChatGPT Enterprise integration

TrojAI

• TrojAI: OpenAI Compliance API integration

Varonis

• Integrating ChatGPT for Enterprise with Varonis SaaS - User Guide

Zenity

• Zenity: AI Agent Security — Zenity for ChatGPT Enterprise

Zscaler

• Zscaler: Adding SaaS Application Tenants