Codex Chrome Extension: Setup, Permissions, 5 Browsers

TL;DR

The interesting bit was never that Codex can open a browser. It is that the browser already has all of your logins. Headless agents have been able to click around the web for two years. What changed is that the agent drives your actual profile, so it can update Salesforce, search Gmail, or scrape an internal Grafana dashboard without you handing over credentials.

Three things have changed since this shipped as a Chrome-only extension in May 2026, and every one of them invalidates advice you will still find on the open web:

• Five browsers, not one. Chrome, Edge, Brave, Opera and Vivaldi are all supported. All five do tab mentions and browser control from the desktop app; Chrome, Edge, Brave and Vivaldi additionally get side chat, a panel that opens beside the page. Opera is the one that does not.
• It is the ChatGPT desktop app now. The Chrome Web Store listing is titled ChatGPT, and OpenAI’s docs call this the browser extension rather than the Codex Chrome extension. The install still starts inside the desktop app.
• The regional block is no longer how the docs describe the gate. At launch, EU and UK were excluded outright. The current documentation says availability depends on rollout and workspace settings instead.

Permissions remain per-site confirmation by default, which is the setting that makes this usable rather than terrifying.

This is not a new browser agent. It is the old browser agent that finally has your session cookie.

If you already use Codex CLI day-to-day, the Codex CLI real-world workflow covers the terminal side. This piece is about the browser bridge: what it does, what it does not, and where it fits in a 2026 coding setup.

What actually launched on May 7

OpenAI released two related things in the first half of May. The Chrome extension landed on May 7, 2026, alongside the Codex desktop app’s Plugins system. The official Codex changelog describes it like this:

“With the new extension for Chrome, Codex is even better at working with apps and websites in your browser. It works in parallel across tabs in the background without taking over your browser, and you stay in control of which websites Codex can use.”

A week later, on May 14, OpenAI added remote connections — the ability to use Codex from the ChatGPT mobile app by tethering to a Mac running the desktop app. Same projects, same plugins, same browser sessions, just operated from your phone. These two updates were designed to be read together: the desktop app becomes the host, and browser plus mobile become the surfaces.

The growth context OpenAI quoted at launch: Codex had more than 4 million weekly active users, up 8x since the start of that year. Treat that as a May 2026 figure; OpenAI has not refreshed it in the changelog since.

What it looks like now

The product moved further than the launch post implied. OpenAI’s browser extension documentation currently describes it as working with Chrome, Edge, Brave, Opera and Vivaldi — the Chromium-family support that was missing at launch arrived, plus Vivaldi. The feature split is worth memorising because it is the only asymmetry:

Two capabilities also appeared that were not in the launch set. Side chat opens ChatGPT next to the page you are reading, keeps itself attached to that tab, and syncs its conversations with the desktop app in both directions. And on a supported side chat you can open a YouTube video and ask about it — when captions exist, the timestamped transcript becomes context, so summarising a conference talk no longer means finding a transcript first.

There is also a built-in browser that ChatGPT can drive instead of yours. It supports sign-in and keeps the work inside ChatGPT rather than in your profile, which is the right choice for localhost and for anything you would rather not run against your real session.

Install: the four steps that actually work

The path is short once you know the order:

1. Install the browser itself, then update the ChatGPT desktop app — do this first, because an outdated app is the single most common reason a supported browser does not show up
2. In the desktop app, find your browser in the connected-apps list and follow the prompt to install the required plugin
3. Follow the link through to the browser’s extension store page and install it, approving the permission prompts
4. Back in the desktop app, confirm the browser shows as connected, then start a chat and select the browser with an @-mention

The non-obvious part is step 1. You install the extension from inside the desktop app, not from the extension store directly. The listing exists on the Chrome Web Store — now titled ChatGPT rather than Codex — but it will not function until the app handshakes with it. Installing in the reverse order gets you an extension that does nothing.

Two gotchas that cost people the most time. Use the browser profile where you installed the extension; a second Chrome profile without it will silently fail to connect. And if your browser still is not listed after updating, that is rollout or workspace policy, not a bug you can fix from your end — the docs are explicit that availability depends on both.

What the extension can actually do

The marketing line is “Codex works in your browser.” That is true but underspecified. Here is the concrete capability list:

• Drive sites where you are signed in. The headline use case. Gmail, Salesforce, LinkedIn, Notion, internal SSO-protected tools, anything your normal Chrome profile can already see.
• Read across multiple tabs. You can ask Codex to compare two product pages, reconcile a spec doc with a ticket, or pull context from a Linear board while writing the code that closes the ticket.
• Use Chrome DevTools. The extension exposes the page debugger, which means Codex can inspect a failing element, read console errors, and check network requests instead of guessing.
• Run in parallel without stealing focus. Background tab operation is the design choice that makes this tolerable. Earlier browser agents would seize the foreground window every few seconds. This one does not.
• Reference your browsing history. Scoped per-request, with a confirmation prompt. Useful for “find that article I read last Tuesday about X” style queries, less useful for anything else.
• Pull in selected text, not just whole pages. Highlight a passage, right-click, and send just that selection into the chat. Cheaper in tokens and far more precise than mentioning the tab.
• Read YouTube transcripts. In a side-chat browser, ask about an open video and the timestamped captions become context, when captions exist.

The capability that quietly does the most work is multi-tab context. A surprising fraction of real coding tasks are “look at this Stripe doc, this internal endpoint, and this GitHub PR all at once, then write the integration.” Before the extension, you had to paste all three into the prompt. Now the agent reads them where they live.

The permissions model — what you are actually agreeing to

The Chrome Web Store listing requests the following permissions:

• Access the page debugger
• Read and change all your data on all websites
• Read and change your browsing history on all your signed-in devices
• Display notifications, manage bookmarks, handle downloads

That is a broad surface. The mitigations are two:

1. Per-site confirmation is on by default. Every new domain triggers a prompt, keyed on the website host. You get four choices: allow once, always allow that site, allow all sites without asking, or block. Only the first two are defensible on a machine with work credentials on it.
2. Allowlist and blocklist apply on top, and they are shared. Manage them in the desktop app next to the browser entry. The important detail: the supported browsers share one set of website permissions, so blocking a domain covers Chrome and Edge and Brave at once rather than per browser. Removing a domain from either list returns it to asking.

OpenAI’s own docs make the prompt-injection point in plain language, twice: treat page content, selected text and video transcripts as untrusted context, and review a site before letting the agent continue on it. That warning exists because the attack is real — a page can contain text written to be read by your agent, not by you.

The configuration I would recommend for a developer using this on a work laptop:

• Keep per-site confirmation on
• Always-allow the two or three sites you are actively automating (your CRM, your monitoring dashboard, your docs)
• Blocklist anything financial, anything HR-related, and anything where a mistake would be expensive

Treat the extension the way you would treat handing a junior engineer your laptop. Useful for clearly scoped work, not for “go figure out what to do.”

Where it fits: three real use cases

The places this earns its keep:

1. CRM and inbox triage. “Look at the three Salesforce opportunities flagged this week, pull the last email thread from each, and draft a follow-up that references the latest call notes.” Without the extension, you do this by hand or wire up the Salesforce and Gmail APIs. With it, the agent drives the actual web app. Slower per click, but zero auth setup.

2. Web app debugging with real session state. A bug that only reproduces when logged in as a specific user role. The extension can open the staging environment, sign in (you are already signed in), click through the broken flow, read the console errors via DevTools, and propose a fix in your local repo. The headless-browser version of this workflow has always been technically possible and practically miserable to set up.

3. Cross-tab research. “Read this OpenAI blog post, this Anthropic doc, and this benchmark page, then draft the migration plan.” Three tabs Codex reads in place. The output is grounded in the actual current text of each page, not in the model’s training data.

For headless code-only tasks — refactors, file operations, terminal commands — keep using Codex CLI. The Chrome extension is the wrong tool for those. If you want the full picture on agent comparison, the coding agents head-to-head article covers where each one fits.

Where it fits in an ofox-based stack

Quick honest framing: the browser extension is bound to the ChatGPT desktop app, which authenticates with your OpenAI account. It does not honor an OPENAI_BASE_URL override, so you cannot route its traffic through an aggregator like ofox.ai. That is an OpenAI direct billing line.

What you can do is split the surfaces:

• Browser extension + ChatGPT desktop app → OpenAI direct, for the signed-in browser tasks
• Codex CLI → routed through ofox via OPENAI_BASE_URL=https://api.ofox.run/v1 and your ofox key, for the headless terminal work

This split is not a workaround. It is the cleanest way to think about it. The extension’s value is access to your signed-in browser profile, and the routing layer cannot help with that. The CLI’s value is portable, scriptable code editing, and the routing layer can give you GPT-5.3 Codex pricing at $1.75 / $14 per million input/output tokens on ofox, plus the ability to A/B against Claude or Gemini through the same key. The AI API aggregation guide explains the routing pattern.

For setup of the routing side, the Codex CLI configuration guide walks through the environment variables. The Codex installation guide covers the desktop app install if you have not done that yet.

What is actually limiting, and what got fixed

Three of the five complaints from launch week are gone. Here is the current state, and it is worth knowing which is which, because the fixed ones still dominate search results.

Fixed: Chromium browsers. Edge, Brave, Opera and Vivaldi are supported. GitHub issue #22638, the tracking thread for exactly this, is still open as of 2026-08-31 — a good reminder that an open issue is not proof a feature is missing. The docs shipped ahead of the tracker.

Fixed, mostly: the regional block. The blanket EU and UK exclusion is no longer stated. The docs now describe availability as dependent on rollout and workspace settings, which is a different and less absolute gate.

Fixed: install-order confusion. The desktop app now walks you through it, including a link straight to your browser’s extension store page.

Still true: Arc is not on the list. Chrome, Edge, Brave, Opera and Vivaldi are. Arc, Zen, and other Chromium forks are not named, and the extension is distributed per-browser-store rather than as a generic Chromium build.

Still true: no side chat in Opera. Tab mentions and browser control work; the panel does not. If side chat is why you want this, Opera is the wrong browser.

Still true: performance varies with tab count. Background-tab operation is the design, but a profile with 80 tabs open will slow things meaningfully. If you live with a lot of tabs, run a dedicated profile.

Still true, and underrated: page content is an injection surface. OpenAI’s docs say it outright. An agent with your session cookie reading attacker-controlled text is a genuinely new risk class, and per-site confirmation is the control that keeps it bounded.

Where this goes next

The launch pairing — browser bridge plus remote connections — read like a two-step roadmap, and the direction held. Step one: drive your real browser. Step two: be reachable from your phone. What happened since is consolidation rather than expansion: the Codex desktop surface folded into the ChatGPT desktop app, the extension became the ChatGPT extension, and the browser list grew from one to five. The agent that has your login state is now a feature of the assistant, not a separate developer product.

For developers, the practical bet is unchanged: keep your code workflow in CLI (routed through whichever provider you trust) and move web-app tasks into the extension one site at a time. CRM updates, support triage, internal-tool automation. Start with the allowlist set to one domain. Add the next one only after the first stops surprising you.

Extension errors and CLI errors have different causes even when the wording overlaps. The Codex error index separates them.

References

• OpenAI browser extension documentation
• Codex changelog
• ChatGPT extension on the Chrome Web Store
• GitHub issue #22638 — Chromium browser support

---

Last updated: August 31, 2026. Browser support matrix, side chat availability and permission behaviour verified against OpenAI’s browser extension documentation on that date; issue #22638 status checked via the GitHub API the same day.

The right way to onboard the Codex Chrome extension is the same way you onboard a junior engineer: one allowed site at a time, with confirmation prompts on, and the blast radius scoped to things a mistake cannot break.

If you want to see how the Codex Chrome extension compares against alternatives in a broader coding stack, the best LLM for coding ranked by real use piece covers model selection, and the coding agents head-to-head covers tooling.

---

Cited sources: OpenAI Codex Chrome extension docs, Codex changelog, Chrome Web Store listing, GitHub issue #22638 on Chromium support.