Configuring Codex Securely Across Every Platform and Use Case

Published: May 3, 2026

Overview

Codex is an agentic tool that started out for just coding, but has expanded to be capable of ‘almost everything’ in the words of their most recent release. With an expanded feature scope, including Computer Use to compete with Claude Cowork, the risk surface is also expanding. Taking actions directly on users’ computers, initiating repeatable automated jobs through ‘Automations’, and a continually growing list of plugins and integrations have led to a formidable sprawl for organization admins to monitor and manage. In this article, we break down the threat model and specific configurations necessary to configure Codex with an appropriate security-functionality trade-off for your use case and users, across platforms and user populations.

The Threat Model

Risk for organizations using Codex varies across the platforms it is used on, the features used, and the types of work they are doing. The primary risk: indirect prompt injection. Hijacking of the user’s agent to accomplish an attacker's means.

This April, we responsibly disclosed an indirect prompt injection vulnerability that allowed for the exfiltration of full, sensitive emails (e.g., legal, health, and security-related) from Codex with no user interaction required – in the default permissions mode.

To combat this risk, organizations can apply controls that reduce risks across two facets – we provide actionable configurations to reduce risks from both:

(1) inputs: reduce the risk of a prompt injection attack by mitigating the processing of untrusted data sources that may contain injections

Examples: restrict connections to plugins that contain externally sourced data, such as email, web data, and files on users’ computers.

(2) outputs: mitigate the potential ramifications of an attack by limiting the sensitive data at risk and the sensitive actions that Codex can undertake without human oversight.

Examples: prohibiting computer use in sensitive apps, ‘full access’ mode that can edit any file on the computer or make any network request, and ‘auto-review’ mode where the agent can choose to leave its sandbox.

Codex is divided into two major sets of features: Codex Local and Codex Cloud. The prompt injection risk surface varies across these two feature sets, and there are steps organizations can take to address untrusted input vectors and sensitive output vectors across both surfaces. Below we threat model each, and then provide configuration advice in the following sections.

Plugins Note: Plugins are both a source of untrusted/sensitive inputs and can be a vector for sensitive action outputs — each plugin enabled increases the risk surface for both Codex Local and Codex Cloud. Global plugin controls apply to all platforms, even beyond Codex. This includes ChatGPT, Atlas, ChatGPT Mobile, and Codex. Plugins follow workspace app controls and can be enabled or disabled by administrators from Workspace Settings > Apps, with per-tool controls available via each plugin's Manage actions menu. These restrictions can be applied using RBAC to allow specific users access to different plugins.

Codex Local Threat Model

Codex Local includes the Codex App, the Command Line Interface, and the Codex IDE extension. For these deployments, the Codex agent operates within a sandbox that runs on the user’s computer.

Codex Local is not covered by the Compliance API; OpenAI states: “Usage in local environments is not available”. Organizations can provide a managed configuration to enable open telemetry, but it is done with the managed_config.toml file, which comes with a caveat: “Users can still change settings during a session”. To work around this, an organization would need to configure a hook in the admin-enforced requirements.toml file.

Codex Local is enabled by default for all new enterprises. If your organization has not yet been able to evaluate Codex Local, or does not intend to allow local use, the feature can be disabled via:
Workspace Settings > Settings and Permissions > Codex Local > Allow members to use Codex Local.

Codex Local is inherently riskier than Codex Cloud, as the boundary between Codex and sensitive user data is minimal. For example, the Codex Desktop App can read any file on the user’s computer, even in the most restrictive permissions mode, ‘default mode’. For comparison, Codex Cloud is restricted to the code files provided to it at start-up.

Another pertinent setting for Codex Local is:
Workspace Settings > Settings and Permissions > Codex Local > Enable device code authentication for Codex CLI.

This setting allows for authentication using sign-in codes, to make it easier to log into development environments that do not have a browser interface. However, as noted by OpenAI, this incurs a risk as if a user is phished for a sign-in code – it will grant attackers immediate access.

The primary mechanisms available to organizations to address risks in Codex Local are via deploying requirements.toml and managed_config.toml files by navigating to https://chatgpt.com/codex/cloud/settings/policies, or using MDM. Details on configuring these files are specified after the threat model.

Codex Cloud Threat Model

Codex Cloud is comprised of the Codex iOS app, Codex Code Review, Codex Web, and the Codex integrations for Slack and Linear. For these surfaces, Codex runs in a containerized environment in OpenAI’s cloud, with access to a user's codebase, packages, and other user-configured elements.

Note: For Linear, GitHub, and Slack integrations — the primary risk lies in how untrusted data sources (e.g., externally sourced Linear issues, PRs from untrusted contributors, and untrusted Slack users) can manipulate the model to access sensitive cloud environments or environments with weak egress settings. Per-integration breakdowns of how this risk applies and necessary integration configurations are at the end of the article.

Codex Cloud users are responsible for configuring their own network access to use with their cloud environments. The ‘Common Dependencies’ configuration provided by OpenAI includes multiple data egress risks, with proven exfiltration attack chains demonstrated by security researchers that are still viable today.

By default, Codex Cloud agents have internet access while running their start-up sequence, for example, to install packages, but do not have internet access while the agent is running unless the environment configuration is modified by users during environment creation.

Cloud environments each have a blanket On or Off setting for Network egress. If Network egress is enabled, a Domain Allowlist policy must be selected. Here is a breakdown of the risks for the different domain allowlist policies:

Organizations are highly recommended to require the configuration of Agent Internet access > Off when creating environments, and if access is required, using the Domain allowlist: None configuration with a specific vetted allowlist of domains for a use case, using a new environment for each use case.

Balancing Functionality With Risks for Codex Local Using Admin-Enforced Requirements and Managed Configurations

Codex provides two primary mechanisms for organization administrators to enforce modifications on Codex Local capabilities. These apply to the CLI, desktop app, and the IDE extension.

We break down the necessary settings to ensure an optimal security-functionality trade-off for several use cases achievable with the Admin-Enforced requirements, and then outline some nice-to-have defense-in-depth, productivity, and observability enhancements one can gain from deploying a Managed Configuration.

Admin-Enforced Requirements (requirements.toml)

Admin-enforced requirements, represented by a requirements.toml file are the primary mechanism to address security-related configurations, and organizations are highly recommended to configure the requirements.toml file in accordance with the needs of their users, to lock down risk surfaces that are not required by the desired user functionality.

To serve differing use cases, admins can write multiple files enforced on different user groups, as well as being able to set a fall-back policy for users who do not have a group.

Note: Per OpenAI documentation, “Codex applies managed requirements on a best-effort basis.” This means that “If no valid [file] is available…, Codex continues without the managed requirements layer.”

These key settings are applied as they are found among several settings locations in the following precedence, where all available files are considered, but if duplicate keys exist, only the highest precedence value for that key is chosen:

1. Cloud-managed requirements

2. macOS MDM distributed requirements

3. System requirements (e.g., local files on the end user’s device)

This configuration can be applied at https://chatgpt.com/codex/cloud/settings/policies.

Organization admins can use the requirements file to address the following:

• When an approval review step is initiated (e.g., never, for all commands not marked trusted, when Codex chooses, or granular rules)

• Who can handle an approval review step (a human or another agent)

• Managed policy instructions for agent approval reviewers

• Specific programmatic policies for when to automatically deny an approval or require a human approval prompt

• Local filesystem read restrictions for agents

• What sandbox modes can users choose to leverage (e.g., writes allowed in the sandbox, reads only with approval for edits, no sandbox at all, a.k.a.’yolo’ mode)

• Whether agents in sandboxed workspaces have network access

• Specific sandbox overrides for different host operating systems (e.g., macOS vs Linux)

• What web search modes are allowed (live, cached, disabled)

• Managed hooks (to take custom actions on specific triggers, like blocking certain command patterns or logging tool call results)

• What MCP servers users are able to configure

• What features are enabled or disabled (e.g., browser use, computer use, in-desktop-app browser pane, memories, multi-agent use)

Managed Configurations (managed_config.toml)

Managed configuration files, represented by a managed_config.toml file, are defaults that can be provided to a user, overriding their local config.toml (the typical file user-level file for customizing a Codex session). These configuration files address a large set of preferences controlling the Codex user experience; providing a managed configuration can save your users time and ensure safe defaults.

Note: managed_config.toml is loaded at the beginning of each Codex session, but users can override these settings during their session – as such, despite some overlapping keys, a managed_config.toml is an insufficient guardrail to restrict sensitive behavior for end users.

When a user’s Codex session loads, config files are applied in the following order of precedence (conflicting keys at lower precedence levels are ignored):

1. MDM distributed managed_config.toml

2. Managed_config.toml in the user’s file system

• Filepath on Linux/MacOS (Unix): /etc/codex/managed_config.toml

• Filepath on Windows/non-Unix: ~/.codex/managed_config.toml

3. Config.toml – the user’s configured Codex preferences

These configuration files support customizing a Codex experience, with functionality including (but not limited to) the following:

• Defining agent personas that Codex can spawn.

• Allowing or disallowing login-shells for shell-based tools (e.g., can shells load user start-up files like ~/.bashrc or ~/.zprofile?)

• Enabling and disabling app connectors and tools for those apps

• Approval policies, approval reviewer policies, and approval rules (just like requirements.toml)

• Overriding the prompt used during context compaction, setting the token limit to trigger compaction

• Overriding the agent’s co-author text on version control system commit messages

• Choosing where to store cached CLI credentials

• Adding developer instructions to the system prompt, agent personality

• A prompt override for how to condense agent memories

• Whether to save memories, after how long to remove them, etc.

• Show or hide agent reasoning

• Whether or not to save chat histories in a local file

• Restrict whether the tool authenticates via API or via ChatGPT

• Manage MCP configurations

• What model to use, reasoning level (chat and plan mode), verbosity of output, context window size, and what model provider to use

• What OTEL telemetry events are configured

• Filesystem reading and writing restrictions

• Network and proxy restrictions

• What file system locations are active projects

• Enabling and disabling skills

• Web search (live, cached, disabled)

• And more: full schema at https://developers.openai.com/codex/config-schema.json

Given that these can be overridden by a determined user mid-session, it is generally not appropriate to treat a managed_config.toml file as a hard-line defense. However, there are still several keys that are likely worth including in a deployment:

Configure OTEL

Example Basic OTLP/HTTPS Configuration

Note: Explicitly setting an exporter to a 'None' configuration saves logs locally but does not export them.

[otel]
environment = "prod"                # dev | staging | prod
log_user_prompt = true              # logs raw user prompts

[otel.exporter."otlp-http"]
endpoint = "https://otel.example.com/v1/logs"
protocol = "binary"                 # "binary" | "json"

[otel.exporter."otlp-http".headers]
"x-otlp-api-key" = "${OTLP_TOKEN}"

[otel.exporter."otlp-http".tls]
ca-certificate = "certs/otel-ca.pem"
client-certificate = "/etc/codex/certs/client.pem"
client-private-key = "/etc/codex/certs/client-key.pem"

[otel]
environment = "prod"                # dev | staging | prod
log_user_prompt = true              # logs raw user prompts

[otel.exporter."otlp-http"]
endpoint = "https://otel.example.com/v1/logs"
protocol = "binary"                 # "binary" | "json"

[otel.exporter."otlp-http".headers]
"x-otlp-api-key" = "${OTLP_TOKEN}"

[otel.exporter."otlp-http".tls]
ca-certificate = "certs/otel-ca.pem"
client-certificate = "/etc/codex/certs/client.pem"
client-private-key = "/etc/codex/certs/client-key.pem"

[otel]
environment = "prod"                # dev | staging | prod
log_user_prompt = true              # logs raw user prompts

[otel.exporter."otlp-http"]
endpoint = "https://otel.example.com/v1/logs"
protocol = "binary"                 # "binary" | "json"

[otel.exporter."otlp-http".headers]
"x-otlp-api-key" = "${OTLP_TOKEN}"

[otel.exporter."otlp-http".tls]
ca-certificate = "certs/otel-ca.pem"
client-certificate = "/etc/codex/certs/client.pem"
client-private-key = "/etc/codex/certs/client-key.pem"

Reach out for custom configuration advice, including how to configure a Trace exporter, Metrics exporter, and OTLP/gRPC configurations.

Configure Storage Location for Cached CLI Keys

cli_auth_credentials_store = "keyring"

cli_auth_credentials_store = "keyring"

cli_auth_credentials_store = "keyring"

Disallow Log-in Shells

allow_login_shell = false

allow_login_shell = false

allow_login_shell = false

Enable Multi-Agent and Define Agents for Common Org Use Cases
Common workflows within one’s organization can be encapsulated in an ‘Agent’ definition, improving the quality of Codex output when working on those workflows through customized workspaces, agent behaviors, and constraints.

[features]
multi_agent = true
[agents]
[agents.my_agent]
description	"Agent to use for task x"	
config_file	= "/path/to/agent/config"

[features]
multi_agent = true
[agents]
[agents.my_agent]
description	"Agent to use for task x"	
config_file	= "/path/to/agent/config"

[features]
multi_agent = true
[agents]
[agents.my_agent]
description	"Agent to use for task x"	
config_file	= "/path/to/agent/config"

Save History for Review in the Case of Model Failures
After compaction, it is sometimes difficult to trace a problem in an active conversation. The ability to review history logs, if necessary, can recover critical otherwise-lost data or context of utility to provide to a future agent session.

[history]
persistence	= "save-all"

[history]
persistence	= "save-all"

[history]
persistence	= "save-all"

Custom Co-Authored Commit Message
Include an attestation affirming liability for model-generated code to encourage users to be more scrupulous; or, disable the Codex commit message if desired.

commit_attribution = "Empty for none, or your custom message"

commit_attribution = "Empty for none, or your custom message"

commit_attribution = "Empty for none, or your custom message"

Disable Memories When External Context is Present

[features]
memories = true
[memories]
disable_on_external_context = true

[features]
memories = true
[memories]
disable_on_external_context = true

[features]
memories = true
[memories]
disable_on_external_context = true

Controlling the Risk Surface with RBAC

Your users do not need every functionality enabled to accomplish their goals – and every extra capability increases risks. With RBAC and granular organization-level configuration files, your users can get the capabilities they need without exposing undue risk.

For granular per-user or per-group permissions, RBAC roles can be configured, allowing organizations to provision roles with access to either or both of Codex Local and Codex Cloud, synced automatically via SCIM.

Note: OpenAI released a new ‘Lockdown Mode’ on April 29th, 2026, that can be assigned via RBAC to limit prompt injection risks. However, Lockdown Mode does not affect Codex products.

As Codex positions its desktop app as a competitor with Claude Cowork, less technical users who are less acclimated to the risks posed by agentic tools, and who have access to even greater amounts of sensitive business data, will be exposed to the tool. This makes it imperative to configure correctly and to limit one's organizational exposure.

Mapping Codex Use Cases to Platforms and Controls

Deployment Checklist

Codex Integrations

GitHub

Codex integrates with GitHub to support cloud environments, but also for Codex Code Review. With Codex Code review, organizations can allow Codex to analyze pull requests.

Code Review is configured on a repository-by-repository basis. We recommend against configuring Codex Code review for repositories containing untrusted contributors, including public repositories.

Untrusted participants can attempt to exploit Codex via prompt injections in pull request contents to enumerate details about the cloud environments they are configured with, which can create a risk if the cloud environment contains any sensitive information. Sensitive information can be present in the cloud environment as a result of scripts run during the environment’s deployment, and environments are configured at the user level, limiting admin oversight.

For each repository, there are two configurations to make: Auto Code Review and Review Triggers.

Auto Code Review determines when Codex should be activated for a specific repository. The options are either ‘Review all PRs’ or ‘Follow personal preference’, which falls back to user-level settings for when to trigger a review.

Review Triggers determines what events cause Codex to initiate a review, and includes the options ‘On pull request open’, ‘On push’, ‘Smart review’ (which allows Codex to choose whether to activate), and ‘Follow personal preference’, which falls back to user-level controls.

At the user level, if ‘Follow personal preference’ is selected for one of the above settings, users can choose whether to have automatic reviews enabled or disabled, as well as whether to trigger reviews on opening pull requests, on pushing code, or using smart review.

Codex Slack Integration

Codex is capable of connecting to Slack, making it possible to query Codex from Slack.

Important Security Note: When Codex is queried from Slack, it chooses what environment to run in. You cannot programmatically control which environment is selected. This means that an attacker can manipulate Codex to choose more sensitive environments, posing a high risk.

For the above reason, we recommend against configuring Codex’s Slack integration, unless it is being deployed solely in channels with highly trusted participants of a similar level of privilege.

Furthermore, it must be noted that Codex in Slack will read the other content in the thread it is working in beyond the message that activated it using @codex. This means that if a sensitive conversation occurs and a user later activates Codex in the thread, the sensitive data from earlier messages will be processed by Codex.

We highly discourage deploying Codex in Slack to channels containing external participants or public channels.

If deploying Codex in Slack to a lower-trust level channel, organizations can disable the Allow Codex Slack app to post answers on task completion setting in their ChatGPT Workspace settings. This will allow users to activate Codex from Slack, but only allow it to reply with a link to the task progress, limiting the ability to reflect sensitive data back to Slack.

Codex Linear Integration

Codex integrates with Linear, allowing users to assign tasks to Codex. This can happen in two ways:

1. An issue is assigned to Codex, the same way issues can be assigned to normal Linear members.

2. Codex is mentioned in a comment using @codex. This triggers Codex to begin work

Note: Issues can be automatically delegated to Codex using Triage rules in Linear, which allow automatic assignment of issues.

When Codex is triggered by an assignment or a comment, it chooses a cloud environment and begins work, reporting back progress to the Linear issue via comments.

Important Security Note: When Codex is activated from Linear, it chooses what environment to run in. You cannot programmatically control which environment is selected. This means that an attacker can manipulate Codex to choose more sensitive environments, posing a high risk.

For the above reason, we recommend against assigning issues to Codex, automatically delegating issues to Codex, or using @ mentions to activate Codex for issues containing untrusted third-party content. Consider the following dangerous flow:

1. A support ticket automatically generates a Linear issue.

2. The support ticket is automatically delegated via a triage rule to Codex.

3. The message submitted by the external party contains a prompt injection that convinces Codex to:

   1. connect to the cloud environment that sounds like it would be the most sensitive

   2. and use bash commands to send the data to attacker.com using any network access available in the cloud environment

Note: The Codex Linear Integration uses Codex Cloud, but Codex Local can access data from Linear, too, via the Linear MCP server. Organizations can control access to this by deploying a requirements.toml file.