Codex gets Chrome plugin to run its coding agent directly in-browser

Browser control is the missing piece if you want a coding agent to do more than write patches. A lot of real software work ends in the browser — reproducing bugs, clicking through flows, checking dashboards, testing logged-in states. That was the gap. On May 7, OpenAI closed some of it by shipping a Chrome extension for Codex that lets the agent work directly in Chrome on macOS and Windows. (developers.openai.com) ### What does the extension actually do? It lets Codex use your local Chrome session instead of a sealed-off browser. In practice, that means the agent can inspect pages, move across tabs, and interact with websites and web apps where you’re already signed in. OpenAI set it up around “task-specific” tab groups, so Codex works inside a bounded set of tabs while you keep using the rest of the browser normally. (developers.openai.com) ### Why is that a big deal for coding? Because browser state is where a lot of bugs live. A coding agent can already edit files, run tests, and check logs. But frontend regressions, OAuth weirdness, checkout failures, admin-panel bugs, and “only happens when I’m logged in” problems often need a real browser with cookies, session state, and live (developers.openai.com)local development servers and file-backed pages. Chrome support extends that into the websites people actually use every day. (developers.openai.com) ### Why not just use a built-in browser? Because a built-in browser is clean. Your real browser is messy — and that mess is useful. Developers debug against production-like states, staging dashboards, internal tools, payment flows, and accounts that are already authenticated. The new extension means Codex can operate where the context already exists instea(developers.openai.com) shortens the gap between “here’s the bug” and “go reproduce it yourself.” (developers.openai.com) ### What are the guardrails? OpenAI is pretty explicit that browser content should be treated as untrusted context. The docs say Codex only stores browser activity when that activity becomes part of the task context — things like text it reads, screenshots, summaries, tool calls, or messages. The extension can also request browser history, but C(developers.openai.com)o steer the agent into exposing data somewhere unintended. (developers.openai.com) ### What does “approval” mean here? The core idea is that Codex does not get a blank check. OpenAI’s security docs say the agent uses sandboxing, approval flows, and network controls, with network access off by default in standard Codex operation. In the Chrome setup flow, users also have to approve Chrome permissions up front. So the model here is supervised automation — not “let the bot roam.” (developers.openai.com) ### Where does this fit in Codex’s rollout? It fits a broader shift from chatbot-style coding help to agentic software work. Over the past few weeks, OpenAI has been adding plugins, memory, in-app browsing, computer use, worktrees, and Windows support to the Codex app. The Chrome extension is another step in the same direction — less “answer(developers.openai.com) (openai.com) ### What changes for developers now? The workflow gets more literal. Instead of pasting screenshots into chat or describing a bug from memory, a developer can point Codex at the actual tabs, let it click through the issue, then review what it did. That matters because modern coding work is not just writing code. It is checking UI behavior, tracing state acros(openai.com)he problem. (developers.openai.com) ### Bottom line This is not just a convenience feature. It turns Codex into more of a working browser-side agent — one that can act inside the messy, authenticated, real-world web context where a lot of software debugging actually happens. (developers.openai.com)