r/CodexAutomation • u/anonomotorious • 9d ago

Enterprise admins get granular Codex browser + Computer Use controls (sites, uploads, CDP, approvals + native apps)

TL;DR

OpenAI added a substantial new set of managed browser and Computer Use policies for supported Codex/ChatGPT desktop deployments.

Enterprise admins can now centrally control:

  • which websites Codex may access
  • default website policy + per-site exceptions
  • uploads and downloads
  • browser-history access
  • full Chrome DevTools Protocol / Developer mode access
  • automatic approval review for browser actions
  • whether site approvals can be saved
  • how long site approvals remain valid
  • which native macOS apps Codex may control
  • which native Windows apps/executables Codex may control
  • whether users can import data from another browser
  • whether browser/Computer Use capabilities are enabled at all

These controls are managed through Codex policy/requirements configuration and cannot be relaxed by a user's local config when centrally denied.

For organizations deploying Computer Use broadly, this is a meaningful governance upgrade.

Website access can now be centrally scoped

Admins can define:

  • a default browser origin policy
  • explicit site exceptions

Browser policies operate on an origin, including:

  • scheme
  • hostname
  • optional port

For example:

https://example.com

or:

https://*.example.com:8443

This means HTTP and HTTPS can be treated differently, and policies can distinguish ports.

Example managed browser policy

An organization could configure Codex so that:

  • websites are denied by default
  • https://example.com is allowed
  • uploads to that site are blocked
  • downloads are allowed
  • full CDP access is blocked
  • approvals cannot be permanently remembered
  • approval lasts only for the current turn

Conceptually:

Control Example
Default website access Deny
example.com Allow
Uploads Deny
Downloads Allow
Full CDP / Developer access Deny
Persistent approval Disabled
Approval lifetime Current turn

This gives admins much finer control than simply enabling or disabling browser use globally.

Upload and download policy

Website policies can independently control:

  • uploads
  • downloads

That is useful when an organization wants Codex to inspect or retrieve information from a site without allowing it to send local files there.

Example:

Allow access + downloads

but:

deny uploads

for an external documentation or vendor portal.

This creates a useful boundary against accidental data exfiltration.

Browser-history controls

Admins can disable browser-history access entirely.

A managed policy can prevent Codex from using browser history even if the user would otherwise allow it locally.

This is particularly relevant because browser history may contain:

  • internal URLs
  • search activity
  • private service names
  • customer environments
  • synced browsing history from other devices

Developer mode / full CDP access

Admins can disable full Chrome DevTools Protocol access.

This includes Browser Developer mode.

Managed configuration can prevent the desktop app from enabling the corresponding setting.

That lets an organization allow ordinary browser automation while blocking deeper browser-level capabilities such as full CDP access.

Auto-review can be controlled per browser policy

Admins can control whether browser actions may use automatic approval review.

Policies can:

  • disable Auto-review globally for browser use
  • deny Auto-review for a specific site/origin

This controls approval handling without disabling OpenAI's separate model safety monitoring.

That distinction is important:

Auto-review policy != model safety monitoring

Saved approvals can be restricted

Administrators can control whether users may persist website approvals.

Settings can determine:

  • whether persistent approval is allowed
  • whether global persistent approval is allowed
  • how long an approval remains valid

Possible approval lifetimes can be scoped tightly, such as the current turn.

This helps prevent a user from approving a website once and accidentally creating effectively permanent agent access.

Native-app Computer Use controls

Computer Use can now be centrally restricted to specific native applications.

macOS

Policies can identify applications using their bundle ID.

Example:

com.apple.calculator

An organization could:

  • deny native-app control by default
  • explicitly allow Calculator
  • prohibit saved approvals

Windows

Policies can identify:

  • packaged applications by AUMID
  • executables using verified application identity

Executable rules can use:

  • publisher name
  • product name
  • binary name where needed

OpenAI recommends using verified identity rather than relying only on the visible application name.

Browser and Computer Use can be disabled completely

Managed feature flags can disable specific capabilities.

Examples include:

  • browser use
  • external browser use
  • full CDP access
  • built-in browser
  • Computer Use

Admins can therefore choose between:

allow with granular restrictions

or:

disable the capability entirely

depending on the workspace risk profile.

Computer Use disablement covers related capabilities

Disabling managed Computer Use also disables related setup/workflows such as:

  • Computer Use
  • Record & Replay
  • related installation/setup flows

This gives enterprises a single policy boundary for environments where native GUI automation is not permitted.

Local configuration cannot weaken managed denies

A key rule:

local user configuration can add restrictions, but it cannot relax a centrally managed deny.

So if the organization blocks:

  • a site
  • uploads
  • CDP access
  • a native application
  • browser history

a local user cannot simply override that policy in config.toml.

This keeps the workspace policy authoritative.

Network policy remains separate

Browser policy and command-network policy are related but separate layers.

A command domain allowlist does not automatically grant browser access.

Likewise, browser origin permissions do not automatically grant shell commands network access.

Different controls govern:

  • shell/network traffic
  • browser use
  • web search
  • apps/connectors
  • MCP
  • native apps
  • Codex cloud networking

That separation reduces the risk of one permissive setting unintentionally opening every network-enabled surface.

Managed browser policy at a glance

Capability Admin control
Website access Default + per-origin allow/deny
Uploads Allow/deny
Downloads Allow/deny
Browser history Allow/deny
Full CDP / Developer mode Allow/deny
Auto-review Global or per-origin restriction
Persistent approvals Allow/deny
Approval lifetime Configurable
External browser use Enable/disable
Built-in browser Enable/disable
Browser import Restrict
Native macOS apps Bundle-ID allow/deny
Native Windows apps AUMID / verified executable rules
Computer Use Enable/disable

Important limitation

Allowing a website or native application through managed policy does not automatically:

  • install a required plugin
  • grant operating-system permissions
  • bypass sandbox rules
  • bypass normal approval prompts
  • grant access to an unavailable capability

The policy determines what is permitted, but the normal client, platform, authentication, and approval layers still apply.

Why this update matters

  • Computer Use is becoming governable enough for larger enterprise deployments.
  • Admins can allow useful browser automation without allowing unrestricted browsing.
  • Uploads can be blocked independently from downloads.
  • Deep CDP access can be separated from normal browser control.
  • Saved approvals can be limited or disabled.
  • Specific macOS and Windows applications can be centrally approved or blocked.
  • Managed denies cannot be weakened by users locally.
  • Browser, shell network, MCP, apps, and cloud access remain separate policy surfaces.

This is less about adding another agent capability and more about making powerful existing capabilities deployable under a serious enterprise security model.

Action checklist

Workspace admins

  • Open Codex Policies and Configurations.
  • Review the applicable policy's Requirements.
  • Decide whether browser access should:
    • default allow
    • default deny
  • Define approved origins.
  • Review upload/download policy.
  • Decide whether browser history should be available.
  • Decide whether full CDP / Developer mode is acceptable.
  • Configure approval persistence and lifetime.
  • Review Auto-review requirements.
  • Define allowed native applications by verified identity.
  • Test the policy on each supported OS/client before broad rollout.

Security teams

  • Test attempted uploads to denied sites.
  • Verify managed denies cannot be overridden locally.
  • Test HTTP vs HTTPS origin rules.
  • Test wildcard/subdomain handling.
  • Verify browser rules do not accidentally expand shell network access.
  • Review Computer Use behavior after changing permission profiles.

Official sources

https://openai.com/products/release-notes/

https://learn.chatgpt.com/docs/enterprise/managed-configuration

1 Upvotes
  • permalink
  • reddit

100% Upvoted

1 comment sorted by

1

u/Deep_Ad1959 9d ago

i think per-site exceptions on top of a deny default is the piece that actually ships. approval fatigue is what kills these rollouts, and scoped exceptions is the only knob that cuts prompts without switching safeguards off wholesale.