Tadashi Shigeoka· Tue, July 14, 2026
Five months ago I wrote a hands-on piece on running Claude in Chrome as a daily driver. Its OpenAI counterpart, the Codex Chrome extension, shipped on May 7, 2026. Community writeups sometimes call it “Codex for Chrome” (paired against Anthropic’s Claude for Chrome name), but OpenAI’s own wording is “Chrome plugin in the Codex app,” so this post sticks with “the Codex Chrome extension.”
I already lean heavily on Codex from the terminal, and I have had the Codex Chrome extension inside my daily workflow since it launched. This post covers those two-plus months of hands-on use: what the Codex Chrome extension is good for and how it splits work with Claude in Chrome.
What the Codex Chrome Extension Is #
The announcement came from OpenAI’s official account on May 7, 2026:
Codex now works directly in Chrome on macOS and Windows.
— OpenAI (@OpenAI)
It’s even better at working with apps and sites in Chrome, and now works in parallel across tabs in the background without taking over your browser.
To get started, install the Chrome plugin in the Codex app.[pic.twitter.com/pjtHd9gC69][May 7, 2026]
The four beats: Codex runs directly in Chrome on macOS and Windows, integration with in-Chrome apps and sites is stronger, tabs can be operated in parallel in the background without stealing the foreground, and install is via the Chrome plugin surfaced inside the Codex app.
The Codex Chrome extension is OpenAI’s official Chrome extension for letting the Codex agent operate your Chrome session. It runs on Chrome on macOS and Windows. Structurally, a Codex session started in the web, desktop, or CLI reaches through the extension into the tab you have open, and drives that tab in your live signed-in state.
OpenAI’s own announcement frames the use cases roughly as:
- Testing behavior of web apps (letting Codex touch a frontend under development)
- Cross-tab context gathering across SaaS tools (Salesforce, Gmail, internal Grafana)
- Debugging with the browser’s DevTools
- Post-login SaaS operation on the user’s behalf
Half of that lineup is developer-workflow-leaning; the other half is the same “human logs in, agent does the rest” model that Claude in Chrome established. By the numbers, OpenAI reports Codex weekly active users grew 8x since the start of 2026 to over 4 million, and the Codex Chrome extension is one of the vectors pulling that curve up.
Setup #
The Codex Chrome extension is not installed directly from the Chrome Web Store. You install it from inside Codex.
- Sign into the Codex app(desktop on macOS or Windows, orchatgpt.com/codexon the web) - Open the Plugins menu and pick Chrome
- You are redirected to Chrome to approve the extension install
- On the first origin you visit, grant Codex per-origin permission to operate
The Chrome permissions the extension asks for are broad: 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
, and Display notifications, manage bookmarks, handle downloads
. That is roughly the maximum permission surface a DOM-driving extension can request. Same story as Claude in Chrome: this is intrinsic to the tool, but understand it before approving.
There are no official builds for Chromium-based alternatives (Brave, Arc, Vivaldi) or mobile Chrome. Again the same posture as Claude in Chrome.
Tasks That Actually Work #
After two-plus months as a daily driver, the tasks I hand off to the Codex Chrome extension fall into three families.
The first is the read-only family, the same one from the Claude in Chrome writeup:
- Summarizing open articles, PDFs, and GitHubPR pages into structured notes - Cross-referencing figures across multiple dashboard tabs ( Grafana,Datadog, theBigQuery console) - Pulling attendee lists and linked docs out of a Google Calendar event, jumping between tabs as needed
The second is post-login SaaS operation, which overlaps with the Claude in Chrome envelope. Where Codex differentiates here is that the extension session is directly continuous with the Codex conversation and execution history you already have going.
- Logging activity in Salesforceor an internal CRM by pulling meeting notes from another tab - Filling out expense-report SaaS entries by matching receipt images against calendar meetings and populating date, amount, category, and purpose
- Drafting tickets in NotionorLinearfrom a template plus context pulled from another tab - Filtering post-SSO internal panels down to records that match a condition
The third family is the new one: developer workflow work that Claude in Chrome does not cover as cleanly.
- Opening a locally running dev server (
localhost:3000
and friends) and having Codex click through it to verify behavior - Reading the DevTools Console and Network tabs so Codex can pinpoint a failing API call
- Diffing DOM structure between production and dev tabs side-by-side
- Manually walking a user flow with the Codex Chrome extension as a precursor to writing a PlaywrightorSeleniumtest, then handing that log back to Codex CLI to draft the test
That last one is where I get the most leverage. The exploratory clicking that used to feed into a manual “and now I write the test” step now feeds directly into a Codex CLI session that is already inside the same account and history. There is no handoff cost between “the thing I clicked in the browser” and “the test I want Codex to write.” That continuity is genuine.
Tasks That Will Bite You #
The tasks to keep away from the Codex Chrome extension look the same as the Claude in Chrome list:
- Anything on a banking or brokerage site
- Anything involving medical or insurance records
- Anything that requires entering credentials, passwords, or API keys
- Anything that ends in an irreversible action (submit, delete, confirm payment)
If anything, the Codex Chrome extension is on the more-dangerous side because it operates a real, signed-in Chrome profile directly. If a page content injection succeeds, the compromised session is your actual Gmail, Salesforce, or GitHub. OpenAI acknowledges this: the Codex Chrome extension defaults to per-site confirmation prompts and only skips them when you explicitly enable “always-allow” for a specific origin.
From a “rolling this out internally” standpoint, the Codex Chrome extension needs a slightly firmer policy posture than Claude in Chrome, in my read. Do not default-install for non-developers, keep the allowlist narrow, and pair with your Codex for Business policy configuration.
How the Permission Model Layers #
The Codex Chrome extension’s permission model is a near-mirror of Claude in Chrome’s, with a couple of differences.
| Layer | What it controls | Who decides |
|---|---|---|
| Per-site Confirmation | Prompt on every new origin | User |
| Always-allow | Skip the prompt for a given origin | User |
| Foreground / Background | Extension operates in background tabs, does not steal the foreground | OpenAI (design) |
| Enterprise Policy | Org-level allowlist / blocklist, extension distribution policy | Org admin |
| Chrome Profile Isolation | Which Chrome profile the extension is installed into | User |
Two differences worth calling out relative to Claude in Chrome. First, there is no explicit Site Blocklist at the Anthropic-equivalent layer (banking, adult, etc.). Codex leans on per-site confirmation plus user responsibility instead of hard blocks. Second, Chrome Profile Isolation becomes a real lever you should use on purpose: I keep separate personal and work Chrome profiles and only install the Codex Chrome extension in the work profile. That gives me a clean line between “what Codex can see” and “what my personal browser sees.”
Splitting Work with Claude in Chrome #
After two-plus months, I have landed on running both extensions rather than picking one. They are complements, not substitutes.
flowchart TD
Q1{Is this dev work or day-to-day work}
Q1 -- Dev work --> Q2{Already inside a Codex session}
Q2 -- Yes --> P1[Codex Chrome extension]
Q2 -- No --> Q3{Need CI reproducibility}
Q3 -- Yes --> P2[Playwright / Selenium as explicit scripts]
Q3 -- No --> P3[Claude Code claude-in-chrome MCP]
Q1 -- Day-to-day work --> Q4{Want continuity with Codex agent history}
Q4 -- Yes --> P4[Codex Chrome extension]
Q4 -- No --> P5[Claude in Chrome side panel]
The pivot question is whether you want the browser session continuous with your Codex agent’s history. The Codex Chrome extension shares an account and execution history with the terminal, IDE, and web Codex sessions, so “write the API in Codex CLI, verify it in the Codex Chrome extension, iterate” flows naturally. That continuity beats Claude in Chrome on developer workflows.
For day-to-day work (expense reports, ticketing, calendar prep) where continuity with the developer side is not needed, the Claude in Chrome side-panel UX is lighter to reach for. Running both in the same Chrome profile has not caused me practical issues in performance.
Honest Take After Running It as a Daily Driver #
Two-plus months in, the concrete thing I can point at is: the depth of what I can hand off inside a single task expanded. Claude in Chrome broadened the horizontal set of tasks that could go to an AI agent. The Codex Chrome extension deepens the vertical, letting a single task carry all the way from terminal to browser and back inside one agent’s history. Those two axes compose.
From the internal-rollout seat, the same warning I gave for Claude in Chrome applies more strongly here. The Codex Chrome extension has fewer hard-block layers than Claude in Chrome (no equivalent to Anthropic’s Site Blocklist), so per-site confirmation and a narrow allowlist are load-bearing. “Default-install and clean up later” is the wrong order.
Wrap-Up #
- The Codex Chrome extension shipped May 7, 2026 for Chrome on macOS and Windows, installed via the Codex Plugins menu (not directly through the Chrome Web Store)
- The Codex Chrome extension covers three families of work: read-only summarization, post-login SaaS operation, and developer workflow (DevTools, local dev servers, cross-tab diffs). The third family is what Claude in Chrome does not cover
- Differences vs Claude in Chrome: no explicit Site Blocklist layer, and Chrome Profile Isolation should be treated as a deliberate control
- In practice, install both. Claude in Chrome for day-to-day work, the Codex Chrome extension for deep developer loops
- For internal rollout, keep per-site confirmation on and start with a narrow allowlist. Do not default-install for non-developers
That’s all from two-plus months of the Codex Chrome extension as a daily driver and mapping it against Claude in Chrome, from the Gemba.