Codex Adds Chrome DevTools Access for Web App Debugging
OpenAI says Codex’s Browser Use can now connect to the Chrome DevTools Protocol, allowing it to inspect running web applications through console logs, runtime errors, local storage, styling, network traffic and performance profiles. The source argues that this moves Codex debugging beyond code inspection: in a slow chat-app example, Codex profiles interactions, identifies duplicate requests and expensive server paths, makes targeted fixes, and reports before-and-after timings. The capability is gated behind Developer mode and per-site approval because CDP access can expose sensitive browser internals.
Codex can inspect the browser, not just the code
Codex’s Browser Use can now use the Chrome DevTools Protocol, giving it access to browser-level information while it works on web applications. The practical change is that Codex is not limited to reading source files. It can inspect the running app through Chrome’s developer interfaces: performance profiles, network traffic, console logs, runtime errors, local storage, and applied styling.
That matters when the bug is not obvious from the code alone. The test case is a small chat app that has become slow as the conversation list has grown. The visible symptoms are familiar: the app takes a while to load, and typing into the chat input is delayed enough to be noticeable. CDP access is presented as a way for Codex to find “true bottlenecks” by profiling specific interactions and looking at the requests the app is making before it starts changing the implementation.
Developer mode is explicit because CDP access is sensitive
The feature is gated behind Developer mode in the Codex app’s browser settings. The settings screen describes the capability as “full CDP access” for connected Browser Use sessions and labels it as an “Elevated risk.” The warning shown in the interface says that full CDP access lets Codex “inspect and control sensitive browser internals” in ways that may put user data at risk.
Full CDP access lets Codex inspect and control sensitive browser internals that may put your data at risk.
That risk model carries into each site inspection. When Codex starts using CDP on a website, the user has to approve the access. The approval dialog shown for http://localhost:3000 gives options to always allow, cancel, or allow the current request.
CDP support is not presented as a background capability silently added to every browsing session. It is a more powerful mode for development work, with a separate setting and an explicit approval step when Codex begins inspecting a site.
The strongest evidence is in the before-and-after timings
The chat app’s problem is described as recent and growth-related: it slowed down “quite significantly,” especially as the list of conversations grew. On screen, the app is a local “Chatbot Demo” running at 127.0.0.1:3000, with a sidebar of prior chats and a text input where the user types “Hello” with visible latency.
Codex is asked to debug the app using Browser Use. The captured baseline trace points toward network behavior. One visible request is a Fetch to /api/conversations?... returning status 200, taking 2314 milliseconds with an encoded size of 29.8 KB. Codex’s visible analysis calls the baseline network capture “pretty incriminating”: the app issued duplicate /api/conversations requests on load, each taking multiple seconds, along with extra summary and preview requests.
| Measurement | Before or after | Value shown |
|---|---|---|
| /api/conversations request | Baseline | about 2.3s and 4.4s for duplicate requests |
| /api/conversations | After restart | 185ms |
| /api/diagnostics?limit=5 | After restart | 35ms |
| / | After restart | 375ms |
| Dev log for /api/conversations | After restart | 182ms, with 14ms in application code |
| Diagnostics scan avoided | Fix described | 54,002 messages no longer scanned on normal API requests |
That initial finding narrows the investigation. Rather than treating the delay as a generic frontend rendering problem, Codex says the slowness appears to start “before rendering settles” and begins checking the server data path.
The final output lists several concrete fixes. Codex removed a 650ms forced render loop and hidden conversation-detail polling from components/chat/chat-app.tsx. It removed unused duplicate summary and marker fetches from lib/chat-client.ts. It also changed expensive diagnostics helpers in lib/db.ts so they used cheaper aggregate metadata rather than scanning 54,002 messages during normal API requests.
The visible result is a smoother chat application, but the more important claim is methodological: the fix is supported by measurements from browser and network inspection, not just by an edit that appears plausible. Codex’s report ties the observed symptoms to duplicate requests, extra traffic, a forced render loop, hidden polling, and a server-side diagnostic path that was too expensive for normal requests.
The work report ties changes to checks
Codex’s work report includes not only changes and measurements, but also checks. It reports that npm run lint passed. It also reports that npm run build passed after rerunning outside a sandbox limitation that had blocked Turbopack helper process binding.
The same report says the browser captured the baseline screenshot and network data, while the Browser plugin blocked the fresh post-fix load on an internal IP or URL policy. Codex says it did not retry or work around that block with another browser surface. The dev server remained available at http://localhost:3000.
The practical value of deeper browser capabilities is that Codex can inspect the running application, make targeted changes, and attach timings and checks to the result.