Codex Chrome extension

What is Codex Chrome extension?

The Codex Chrome extension enables Codex to run browser tasks in Chrome when the task requires the user’s signed-in browser state. It’s designed for workflows where Codex needs to read or act on websites such as LinkedIn, Salesforce, Gmail, or internal tools.

When you don’t need sign-in (for example, local development servers, file-backed previews, or public pages), the documentation recommends using the in-app browser first so preview and verification stay inside Codex instead of using your Chrome profile.

Key Features

• Connect via the Codex app by installing or connecting the Chrome plugin from Codex → Plugins, then approving Chrome permission prompts during setup.
• Use Chrome only when needed for authenticated workflows (Codex can suggest Chrome for tasks requiring signed-in context, and you can invoke it explicitly in a prompt like @Chrome).
• Keep thread work organized: browser tasks run in Chrome tab groups so activities for a thread stay grouped together.
• Control access to websites with per-host confirmation by default, including options to allow for the current chat, always allow a host, or decline.
• Manage domain-level permissions using allowlist and blocklist in Computer Use settings (removing a domain from allowlist or blocklist changes whether Codex asks again).
• Optional “always allow browser content” with elevated risk: when enabled, Codex skips confirmation before using websites.
• Scoped browser history access with additional prompts: history can include sensitive telemetry, internal URLs, search terms, and activity from signed-in devices; access is requested by Codex and scoped to the request (no always-allow option is provided for history).

How to Use Codex Chrome extension

1. In the Codex app, open Plugins.
2. Add the Chrome plugin and follow the setup flow to install or connect the Chrome extension and approve any Chrome permission prompts.
3. Open Chrome and confirm the Codex extension shows Connected.
4. Start a new Codex thread and proceed with a task; Codex can suggest Chrome when a signed-in browser context is required.
5. If needed, explicitly invoke Chrome in your prompt using @Chrome (e.g., “@Chrome open Salesforce and update the account from these call notes”).

During use, review confirmation prompts before Codex accesses new websites or before any browser history access is granted.

Use Cases

• Update accounts or records in signed-in business apps: have Codex use Chrome to work inside a site like Salesforce where the signed-in session is required.
• Review and act on authenticated communications: use Chrome to read or perform actions in Gmail when the task depends on being logged in.
• Execute workflows against internal tools: when internal pages require an authenticated browser state, allow Codex to access those specific website hosts.
• Reduce exposure for public or non-signed-in tasks: for local development servers, file-backed previews, and public pages that don’t require sign-in, run the work in the in-app browser first to avoid using your Chrome profile.
• Handle risk-sensitive browsing content: use the default confirmations (or maintain allowlist/blocklist settings) so Codex prompts you before interacting with new websites and before including page or history content in the thread context.

FAQ

• Does OpenAI store a complete record of my Chrome actions from the extension? No. The documentation states OpenAI doesn’t store a separate complete record of your Chrome actions. Browser activity is stored only when it becomes part of Codex context (for example, text read from a page, screenshots, tool calls, summaries, messages, or other content included in the thread).

• When should I use the in-app browser instead of Chrome? Use the in-app browser for local development servers, file-backed previews, and public pages that don’t require sign-in. Chrome is for browser tasks that need your signed-in browser state.

• How does Codex decide whether to ask before accessing a website? By default, Codex asks before it interacts with each new website based on the site host. You can allow for the current chat, always allow a host, or decline.

• What are the risks of enabling “always allow browser content”? Turning it on disables confirmation for website usage. The documentation notes this is an elevated risk setting.

• What about browser history access? Codex asks when it wants to use browser history. History can include sensitive telemetry, internal URLs, search terms, and activity from Chrome sessions on signed-in devices. History access is scoped to the request and has no always-allow option.

Alternatives

• Codex in-app browser (within the Codex app): Use this for tasks that don’t require a signed-in Chrome session, keeping preview and verification work inside Codex.
• Manual web interactions plus Codex assistance: If you prefer to avoid granting Chrome access, you can do the authenticated steps yourself and use Codex for planning, extracting key points, or drafting changes based on what you provide.
• Other authenticated browser automation approaches: For workflows requiring login, you can use browser-based tools or automation that operate within a dedicated browsing environment, rather than tying execution to a user’s Chrome profile.
• Domain-specific permission management in similar agent tools: If you want the same pattern of allowlisting and per-host approvals, look for tools that offer domain-level controls and request-based access instead of blanket permissions.