Letting Codex Drive Your Browser with the Codex Chrome Extension — Hands-On Impressions and Splitting Work with Claude in Chrome

OpenAI's Codex Chrome extension, launched May 7, 2026, lets the Codex agent operate Chrome on macOS and Windows, with parallel tab control and integration with in-Chrome apps. OpenAI reports Codex weekly active users grew 8x since the start of 2026 to over 4 million, with the extension as a key driver. The extension requires broad permissions and is installed via the Codex app, not the Chrome Web Store.

Letting Codex Drive Your Browser with the Codex Chrome Extension — Hands-On Impressions and Splitting Work with Claude in Chrome Tadashi Shigeoka /en/author/tadashi-shigeoka/ · Tue, July 14, 2026 Five months ago I wrote a hands-on piece on running Claude in Chrome as a daily driver /en/posts/claude-in-chrome-browser-automation-hands-on/ . Its OpenAI counterpart, the Codex Chrome extension https://openai.com/codex/ , shipped on May 7, 2026. Community writeups sometimes call it “Codex for Chrome” paired against Anthropic’s Claude for Chrome https://claude.com/blog/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 https://openai.com/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 https://openai.com/index/introducing-codex/ 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 https://openai.com/codex/ desktop on macOS or Windows, or chatgpt.com/codex https://chatgpt.com/codex on 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 https://brave.com/ , Arc https://arc.net/ , Vivaldi https://vivaldi.com/ 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 GitHub https://github.com/ PR pages into structured notes - Cross-referencing figures across multiple dashboard tabs Grafana https://grafana.com/ , Datadog https://www.datadoghq.com/ , the BigQuery console https://console.cloud.google.com/bigquery - 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 Salesforce https://www.salesforce.com/ or 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 Notion https://www.notion.com/ or Linear https://linear.app/ from 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 Playwright https://playwright.dev/ or Selenium https://www.selenium.dev/ test, 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 https://openai.com/index/introducing-codex/ 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 https://learn.chatgpt.com/docs/enterprise/admin-setup 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. php 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.