OpenAI adds an in-app browser and computer use to Codex, aimed squarely at frontend iteration

The visual feedback gap this release is trying to close

Frontend work has always been awkward for code agents. Writing a React component is a text problem; knowing whether the rendered result looks right is not. Until now Codex could produce the markup but not see the pixels, which meant a human had to run the app, look at it, and describe what was wrong back in prose.

This update attacks that gap directly. OpenAI names "iterating on frontend changes, testing apps, or working in apps that don't expose an API" as the motivating use for background computer use, and calls the new in-app browser "useful for frontend and game development today." The pattern is consistent: the features that ship first are the ones where the agent needs to observe a running interface, not just edit files.

Commenting on a page instead of describing it

The most concrete frontend mechanic here is the in-app browser where, per OpenAI, "you can comment directly on pages to provide precise instructions to the agent." That inverts the usual instruction flow. Instead of typing "the button in the header is misaligned," you point at the button in the rendered page.

This is spatial context that text prompts lose. A comment anchored to a DOM element carries which element, where it sits, and what it currently looks like — the exact information a developer would otherwise transcribe by hand and the agent would otherwise have to guess at.

This is useful for frontend and game development today, and over time we plan to expand it so Codex can fully command the browser beyond web applications on localhost.Montana Labs

Note the boundary OpenAI draws: today the browser is scoped to localhost web apps. The ambition to "fully command the browser" is stated as future work, not shipped capability.

Computer use and image generation as design tooling

Background computer use lets Codex operate a Mac with its own cursor, "seeing, clicking, and typing," and run multiple agents in parallel without taking over your keyboard. For frontend work that means the agent can drive design tools and test harnesses that have no programmatic interface — a large class of software that API-based automation simply couldn't touch.

Alongside this, Codex can now call gpt-image-1.5 to generate and iterate on images. OpenAI positions this for "product concepts, frontend designs, mockups, and games inside the same workflow." Combined with screenshots and code, the agent can produce a mockup, implement it, view the result in the in-app browser, and adjust — a loop that previously spanned several disconnected tools.

The Remotion and Render plugins in the batch of 90-plus additions round this out toward video and deployment, though OpenAI gives no detail on how deeply those integrate.

What frontend teams should actually test first

The honest read is that these are the early, scoped versions of harder capabilities. Computer use is macOS-only at launch and rolls out to EU and UK users "soon." The browser handles localhost. Memory and context-aware suggestions are previews gated behind Enterprise, Edu, and later EU/UK availability. None of this is a finished autonomous frontend engineer.

The specific thing worth evaluating is whether the observe-and-comment loop reduces the transcription tax on visual bugs. If pointing at a misrendered element and letting the agent both see and fix it is faster than describing it in text, that is a measurable workflow change for teams doing heavy UI iteration. If the agent's browser vision is unreliable, it becomes another tool you supervise as closely as one you'd operate yourself. That is the test this release sets up, and it's the one to run on a real component before restructuring anyone's workflow around it.