Securing Codex Best Practice

The twelve things to know before enabling Codex for your organization.

1. Treat Codex like a coworker with tools, not a passive chatbot. It handles long-running, browser-connected, and automation-driven tasks.
2. workspace has two meanings: the ChatGPT admin container, and the local project folder Codex operates in. workspace-write refers to the local sandbox boundary only.
3. The safe baseline is sandbox_mode = "workspace-write" with approval_policy = "on-request". Useful inside the sandbox; not approval-free.
4. Keep danger-full-access and approval_policy = "never" away from normal users. Reserve them for tightly contained non-interactive jobs or break-glass cases.
5. requirements.toml matters most. It enforces admin limits on sandbox modes, approval policies, web search, and MCP servers that users cannot override.
6. RBAC is split. ChatGPT workspace roles cover Codex workspace features. OpenAI Platform roles cover API projects and Agent Builder. Review both separately.
7. Prompt injection connects every risk. Web pages, docs, AGENTS.md, MCP responses, and plugin output can carry hidden instructions. Keep command network access off by default.
8. Browser and desktop surfaces need their own policy. In-app browser, Browser Use, Chrome extension, Computer Use, and Atlas can expose signed-in accounts, screen contents, and clipboard state.
9. Cloud, GitHub, Slack, Linear, mobile, and SSH are separate from local Codex. A local sandbox does not protect a hosted container or GitHub App installation.
10. Apps, MCP servers, plugins, skills, hooks, and repo instructions are supply chain. Allowlist what is approved; review changes to AGENTS.md and .codex/ like code.
11. Background work needs stricter containment. Automations and CI jobs run without a human watching. Test prompts manually, use worktrees, and define stop conditions.
12. Audit is split across systems. Analytics for adoption, Compliance API for investigations, OTel for runtime visibility. Route key streams to your SIEM before broad rollout.

Workspace

workspace has two meanings in OpenAI documentation.

A ChatGPT workspace is the enterprise admin container: where owners and admins manage members, groups, roles, workspace permissions, Codex enablement, apps, analytics, identity, and compliance settings.

A local Codex workspace is the project folder, worktree, or configured workspace root where Codex is operating on a user's machine or in a task environment. This is the boundary that matters when you see workspace-write.

Practical rule: if you are in ChatGPT Admin or an Analytics/Compliance API path, say ChatGPT workspace. If you are configuring sandbox_mode, workspace-write, or writable_roots, say local workspace or workspace root.

Defaults versus requirements

config.toml and managed_config.toml set starting behavior. requirements.toml sets admin-enforced limits -- for example, locking allowed_sandbox_modes to ["read-only", "workspace-write"] -- that users cannot weaken.

Agents

OpenAI uses the word agent in several product areas. They are related concepts, but they are not governed from one place.

• Workspace agent: created in ChatGPT from the Agents sidebar; governed by ChatGPT workspace settings and visible in the Global Admin Console agents inventory.
• Platform Agent Builder workflow: built at platform.openai.com/agent-builder; published with a workflow ID and deployed through ChatKit or the Agents SDK/API.
• Codex subagent: a worker thread inside a Codex session; inherits the current Codex sandbox and approval policy.
• Codex cloud task, ChatGPT Agent Mode, and API-built agents are separate surfaces. Use the product name in policy language instead of saying "agents" by itself.

Surfaces are separate

Local Codex, Codex cloud, GitHub Code Review, Slack/Linear tasks, mobile, Remote Connections, SSH, workspace agents, Platform Agent Builder, Browser Use, Chrome, Computer Use, MCP servers, and Atlas do not share one switch or one audit path. Treat each as its own surface with its own enablement, scope, and evidence source.

Use one of these three postures to scope the rest of the guide.

Lockdown

For regulated work, production infrastructure, confidential IP, legal/HR/finance workflows, or early pilots.

• Small approved group only; Codex cloud disabled unless separately approved.
• SSO + MFA enforced; read-only sandbox by default.
• Approvals: on-request only; no broad always-allow rules.
• All browser/desktop surfaces (Atlas, Browser Use, Chrome, Computer Use) disabled.
• Web search disabled or cached; shell network off; MCP/apps/plugins/skills allowlisted only.
• Automations disabled or read-only; Compliance API + OTel logging required.

Controlled

For most managed organizations after a pilot. Codex is productive inside a local project; browser, network, and extension surfaces are explicitly governed.

• Codex Users group + small Codex Admin group; ChatGPT workspace login for humans.
• workspace-write sandbox; deny-read for secrets and credential stores.
• on-request or granular approvals; auto-review only if policy accepts it.
• In-app browser for localhost/unauthenticated pages only; Chrome, Computer Use, and Atlas by approved role or exception.
• Cached web search; shell network off unless a domain allowlist is defined.
• Approved MCP/app/plugin/skill inventory with owners and review dates; Analytics + Compliance API + OTel routing.

Open

For low-sensitivity repos, disposable environments, isolated VMs, or expert teams with strong external containment.

• workspace-write default; Full Access only inside externally hardened environments.
• Browser/desktop surfaces enabled only with review, training, and allowlists.
• Domain allowlist before unrestricted network; mandatory logging because autonomy is higher.

The open posture should be an exception with external containment, not the default for a managed laptop with broad access to corporate data.

Codex risk is cumulative across surfaces. Inventory all of them before focusing on model quality or user training.

Local runtime

Codex app, CLI, IDE extension, codex exec, SDK, and CI/GitHub Actions. Risks: file exposure, destructive commands, secret reads, CI secret exposure, and public-trigger abuse. Use read-only or workspace-write; deny-read secrets; filter environment variables; run CI as an unprivileged user; sanitize prompts from issues, PRs, and commits.

Remote connections and SSH

Control this Mac, Control other devices, SSH hosts, Codex mobile, and always-on Macs. A remote device inherits the host's projects, files, credentials, MCP servers, Computer Use, and local tools. Enable Remote Control for approved groups only; inventory and remove stale paired hosts; treat SSH like normal privileged access.

Browser and desktop

In-app browser, Browser Use, Chrome extension, Computer Use, Atlas, and Agent Mode. Risks include prompt injection from web pages, signed-in browser actions, screen/clipboard exposure, and Atlas compliance gaps for regulated use. Keep the in-app browser to localhost and unauthenticated pages; require per-site approval for Chrome; review macOS Screen Recording and Accessibility permissions for Computer Use.

Cloud, GitHub, and integrations

Codex cloud, GitHub Code Review, hosted PRs, Slack/Linear-created tasks, and mobile-initiated work. Risks: repo exposure, GitHub App overreach, setup-script supply chain, and untrusted PR prompt injection. Scope GitHub access to approved repos; keep branch protection on; review setup scripts; keep agent internet access off or allowlisted.

Agents and background work

ChatGPT workspace agents, Platform Agent Builder workflows, API-backed agents, automations, and Codex subagents. Risks: agent-owned connections, unattended schedules, API key exposure, and service-account overreach. Separate build and publish permissions; restrict agent-owned connections; block Full Access background work; keep subagent tasks explicit and bounded.

Extension and tool supply chain

Apps, MCP servers, plugins, skills, hooks, repo instructions, and .codex/ content. Risks: data exfiltration, credential forwarding, code execution, and hidden instruction paths. Start with a narrow allowlist; scope OAuth credentials; keep side-effecting tools on prompt; review skills and hooks like code; assign owners and review dates.

Codex risk often hides in the gaps between settings pages. The most useful security work is concrete: decide which surfaces are enabled, who can use them, what policy applies, and where the evidence lands.

Workspace enablement and RBAC

Start in ChatGPT Admin settings under Workspace Settings > Permissions & roles. This is where owners enable Codex Local, Codex cloud, the GitHub Connector, and Remote Control. Use custom roles, Groups, and SCIM-backed IdP groups to separate a small Codex Admin group from a broader Codex Users group. Also review adjacent controls: Atlas, Agent Mode, Memory, apps/connectors, GPT sharing, and link sharing.

ChatGPT workspace agents

Adjacent to Codex, but governed from the ChatGPT workspace and Global Admin Console -- not from Codex settings.

In ChatGPT workspace RBAC, review permissions for agent enabling, building, publishing, and publishing with agent-owned connections. Agent-owned connections are the highest-risk setting: other users may be able to access data through a builder's personal credentials. Prefer end-user authentication or a reviewed service account.

Managed Codex policies

Codex Admins can use the Codex Policies page to deploy cloud-managed requirements.toml policies. These policies apply to ChatGPT-signed-in Codex local surfaces, including the app, CLI, and IDE extension.

This is the most important local-runtime control. For most users: lock allowed_sandbox_modes to read-only/workspace-write, allowed_approval_policies to on-request/granular, allowed_web_search_modes to disabled/cached, and pin browser_use, in_app_browser, and computer_use to false.

• Create a baseline policy for most users, then stricter or more permissive variants only where needed.
• Configure a default fallback policy so users outside explicit groups still receive a safe policy.
• Order group rules carefully. If a user matches more than one group-specific rule, the first match applies.
• Treat each policy as a complete profile. Codex does not fill missing fields from later matching group rules.
• Use the policy lookup tool to confirm which policy applies to real pilot users before rollout.

Local app settings

The Codex desktop app controls several high-risk user-facing surfaces: Plugins, Browser Use, the Chrome plugin, Computer Use, Automations, Memories, Skills, Connections, and local preferences. Some of these can be constrained with managed policy, but users and admins should still review what is enabled in the app.

Use the least powerful browser or desktop surface that solves the task. A localhost preview does not need the user's signed-in Chrome profile, and a structured SaaS lookup usually should not start with visual browser automation.

• Disable Browser Use, Chrome, and Computer Use for lockdown groups through managed feature pins.
• Keep "Always allow browser content" off for most users.
• Remove stale website and app allowlist entries during access reviews.
• Remove stale paired devices and SSH hosts during access reviews.
• Review Memories and skills before enabling them for sensitive workflows.
• Test automations manually before scheduling them, and prefer worktrees for Git repositories.

Codex cloud, GitHub, Slack, Linear, and Code Review

Treat cloud separately from local Codex. The local sandbox does not protect hosted containers, GitHub App installations, or Slack/Linear-created tasks. Scope the GitHub Connector to approved repos; review setup scripts; keep agent internet access off unless a narrow allowlist is justified; configure Code Review by repository and trigger rather than enabling it globally.

Governance, analytics, compliance, and OTel

Use the Codex analytics dashboard for usage and Code Review reporting, the Compliance API for audit exports and investigations, and OpenTelemetry (OTel) for SIEM visibility into local runtime events. Configure all three before broad rollout.

OTel is disabled by default. Configure it via [otel] in requirements.toml (not project-local config). Set log_user_prompt = false unless your policy explicitly allows prompt-content collection -- prompts can include source code, credentials, and customer data. Export Compliance API logs to SIEM/DLP/eDiscovery for retention beyond the platform window, and track usage by surface to spot shifts from local to cloud or browser workflows.

The ChatGPT workspace and OpenAI API Platform can belong to the same enterprise environment but have separate roles, identifiers, and audit paths. Codex admins will encounter both.

What lives where

The ChatGPT workspace governs: member and group access, Codex Local and cloud enablement, managed policies, workspace agents, apps/connectors, Memory, GPTs, Atlas, Agent Mode, and workspace-level analytics and compliance.

The OpenAI API Platform governs: Platform RBAC, project membership, API keys, service accounts, model permissions, rate limits, data controls, ChatKit, Responses API, Agents SDK, and Agent Builder workflows. These are separate roles, identifiers, and audit paths.

Agent types have different security owners

• Workspace agent: created in ChatGPT; governed in the ChatGPT workspace and Global Admin Console.
• Platform Agent Builder workflow: built in OpenAI API Platform; deployed through ChatKit or API/SDK code. Review like software -- project owner, API key owner, tool owner, data-retention owner.
• Codex subagent: parallel worker inside a Codex session; inherits the Codex sandbox and approval policy.
• Codex cloud task: hosted task running against a connected GitHub repository.

API keys and service accounts

Keep personal API keys out of CI and scheduled automation. Use project-scoped service accounts, separate projects by data class, rotate keys, and remove unused ones. For codex exec and GitHub Actions, capture runner logs, tool output, key owner, project ID, and trigger source. ChatGPT Compliance API exports do not cover API-key automation the same way they cover ChatGPT-authenticated flows.

Data controls span both platforms

Platform data-retention controls are set at the API organization and project level -- separate from ChatGPT workspace retention, residency, and compliance settings. Document both paths for any workflow that crosses the boundary.

Local Codex

Codex defaults to workspace-write + on-request for version-controlled folders, and read-only for others. Users can still choose broader modes unless admins enforce requirements.toml. Block danger-full-access and approval_policy = "never" for interactive users; add deny-read rules for secrets and credential stores.

Web search and command network access

Web search defaults to cached (OpenAI-maintained index, not live pages). Command network access is off by default in workspace-write. For managed users, allow only disabled or cached; if live network access is needed, use an administrator-owned domain allowlist rather than a broad * rule.

In-app browser and Browser Use

The in-app browser is designed for localhost, file previews, and public unauthenticated pages. Browser Use asks before operating a site unless already allowed. Use managed feature pins for stricter groups, and review allowed/blocked site lists during access reviews.

Chrome extension

The Chrome extension handles tasks that require a signed-in browser state. Codex asks before each new website host, but approved actions happen inside the user's signed-in context. Require explicit approval for admin consoles, customer systems, payment flows, and HR/legal/finance tools.

Computer Use

Computer Use lets Codex see and operate graphical macOS apps after Screen Recording and Accessibility permissions are granted. Screen contents, open files, and clipboard state become model-visible. Keep it off for lockdown groups, remove stale Always-allow entries, and require users to stay present for sensitive flows.

Codex cloud

The cloud setup phase can access the network to install dependencies, but the agent phase runs offline by default. Local sandbox settings do not protect cloud containers, GitHub App installations, Slack/Linear-created tasks, or Code Review triggers.

Automations and subagents

Automations inherit the user's default sandbox settings. With Full Access, background automations carry elevated risk. Subagents inherit the current sandbox policy. Test automations manually, prefer worktrees, block Full Access background work, and define stop conditions.

Apps, MCP, plugins, skills, and hooks

Destructive app/MCP tool calls always require approval when the tool advertises a destructive annotation. App outputs, MCP responses, plugin code, skills, hooks, and .codex/ content are supply chain inputs. Start with a narrow allowlist, keep side-effecting tools on prompt, and review ownership, scopes, and credential handling before broad rollout.

Validate these against your actual workspace before publishing policy — plan names and feature availability can change.

Investigation path by surface

• Test every automation manually before scheduling it.
• Use durable prompts with scope, stop conditions, and reporting expectations.
• Prefer read-only for reporting automations and workspace-write for maintenance automations.
• Disallow Full Access background work outside isolated environments.
• Use worktrees for Git repositories and review the first several runs before trusting the schedule.
• Include plugins, skills, hooks, and MCP servers in the automation approval.
• Use subagents only for explicit, bounded work; do not treat them as a separate security boundary.

High level only — a separate supplement should map each control to specific CSF 2.0 and AI RMF subcategories.

Do not make the first rollout a feature tour. Start with the surfaces users actually need, prove the policy applies to real users, connect the audit trail, and then widen access by group and use case.

Phase 0: Inventory and owners

• Name owners for workspace admin, Codex admin, security policy, endpoint management, analytics/compliance, and incident response.
• Decide which surfaces are in scope and classify repositories by sensitivity.
• Inventory existing configs, agents, API keys, paired devices, SSH hosts, MCP servers, plugins, skills, and hooks.

Phase 1: Pilot

• Small Codex Users group + smaller Codex Admin group; workspace-write + on-request; no Full Access; Browser Use, Chrome, and Computer Use disabled.
• Configure managed requirements and a default fallback policy; wire Analytics, Compliance API, and OTel before expanding.
• Verify a real pilot user receives the expected policy.

Phase 2: Controlled expansion

• Create group-based profiles (lockdown, controlled, open); establish an MCP/app/plugin/skill review process.
• Enable cloud only for selected repos with branch protection; add automation templates; train users on approvals, diffs, and prompt injection.

Phase 3: Operate

• Analytics: monthly. Compliance/OTel/SIEM alerts: weekly. Browser, Computer Use, Remote Connections, MCP, and automation exceptions: fixed cadence.
• Red-team prompt injection, exfiltration, destructive commands, and tool abuse quarterly. Revisit policy after incidents or major Codex releases.

Access and identity

• Codex Users and Codex Admin groups exist.
• Admin role is small and SCIM-backed.
• SSO/MFA is enforced.
• ChatGPT workspace login is forced for managed human use where possible.
• API-key use is limited to scoped automation.
• OpenAI Platform roles are reviewed separately from ChatGPT workspace roles.

Local runtime

• Default sandbox is workspace-write or read-only.
• Full Access is blocked or exception-based.
• Approval policy is on-request or granular.
• Auto-review policy is documented if enabled.
• Deny-read covers secrets and local credential stores.
• Local history, logs, analytics, feedback, and memories policy is defined.
• Web search is disabled or cached unless live search is explicitly approved.

Browser and desktop

• In-app browser policy is defined.
• Chrome extension use is approved only for defined groups or use cases.
• Atlas and ChatGPT Agent Mode are disabled or limited to a low-risk pilot.
• Website allowlists/blocklists are reviewed.
• Browser history access is understood and not always allowed.
• Computer Use is disabled or app-scoped.
• macOS Screen Recording and Accessibility permissions are reviewed.
• Connections, paired devices, and SSH hosts are reviewed.

Tools and background work

• MCP/app/plugin/skill allowlist exists.
• Side-effecting tools prompt for approval.
• Plugin hooks are disabled or reviewed.
• Workspace agent build, publish, and agent-owned connection permissions are reviewed.
• Platform Agent Builder permissions, project roles, API keys, and service accounts are reviewed.
• Automations are tested manually before scheduling.
• Full Access background automations are blocked.
• Subagent guidance is documented.

Cloud, GitHub, and audit

• Cloud is enabled only for approved groups/repos.
• GitHub App installation is repo-scoped.
• Setup scripts and secrets are reviewed.
• Code review triggers are controlled.
• Slack/Linear/mobile initiation, Remote Connections, and SSH use are monitored where enabled.
• Compliance API export is connected to SIEM/DLP/eDiscovery.
• OTel export is connected to a SIEM or telemetry collector, with prompt contents redacted unless explicitly approved.
• Incident runbook covers tokens, MCP grants, apps, automations, browser/desktop permissions, and hooks.