Codex handles frontend work best when you give it a visual target and a way to check its result: attach screenshots or a Figma frame, point it at your existing components, and let it open the page in a browser to compare. OpenAI's frontend use case describes exactly that loop: Codex translates screenshots into code that fits your design system, then uses Playwright to compare the build with your references at different screen sizes.
This guide covers the inputs Codex accepts, the two ways it can check UI in a browser, the Figma route, and how to keep its output consistent with your codebase. Facts come from OpenAI's docs, read on 26 October 2026.
What can Codex do on a frontend codebase?
Codex reads your repo, edits files and runs commands, so most frontend chores are in scope:
- Build screens from references. Turn screenshots, a short design brief or a Figma selection into components that use your existing primitives.
- Fix visual bugs. Reproduce an overflow or clipping issue in a browser, patch the CSS, and check the fix.
- Refactor and type. Split large components, tighten TypeScript types, and update imports across the project.
- Debug in the browser. With Developer mode on, inspect console output, network traffic, the DOM and applied styles.
- Check responsive layouts. Resize the browser across breakpoints and compare each one with your references.
Where Codex runs matters. The ChatGPT desktop app has a built-in browser and an integrated terminal next to the chat. The Codex CLI and IDE extension don't have the browser, so on those surfaces you verify UI through a Playwright skill instead.
How do you give Codex screenshots and designs?
OpenAI's image inputs page lists one method per surface:
| Surface | How to attach an image |
|---|---|
| ChatGPT desktop app | Drag an image into the composer while holding Shift |
| Codex CLI | Paste into the composer, or pass -i / --image |
| IDE extension | Drag an image into the composer while holding Shift |
In the CLI, separate several paths with commas or repeat the flag. This command comes from OpenAI's docs:
codex --image before.png,after.png "Compare these states and list the regressions"
Images work best with a prompt around them. The docs advise you to "Name what the image shows, point to the area that matters, and state the output and constraints." If you attach more than one, say which is which.
The frontend use case adds advice on references. A single screenshot can be enough for a narrow task, but the handoff improves when you include desktop and mobile layouts, hover or selected states, and any empty or loading views that matter. The references don't need to be polished design files. They need to make hierarchy, spacing and direction concrete. The Codex images guide covers formats and limits.
How does Codex check its UI in a browser?
There are two documented routes.
The built-in browser in the ChatGPT desktop app. OpenAI's browser docs describe it as "a shared view of websites and local web apps inside a chat." Start your dev server in the integrated terminal, open the local route, and Codex can click, type, inspect rendered state, take screenshots and verify its own changes. Reference it in a prompt with @Browser. This example is from OpenAI's docs:
Use the browser to open http://localhost:3000/settings, reproduce the layout
bug, and fix only the overflowing controls.
For feedback that's easier to show than describe, select Annotate in the browser toolbar, click an element or drag over an area, and write a comment. Then ask Codex to address your comments. The Adjust control on an annotation lets you change values such as font, spacing and color, preview them on the page, and send that as a clearer target. For performance or network bugs, Developer mode gives Codex controlled access to the Chrome DevTools Protocol after you turn on Enable full CDP access under Settings > Browser. Codex asks for approval before it uses full CDP on a site.
The built-in browser uses its own profile, separate from your regular browser, and treats page content as untrusted. Codex can't automate file uploads there.
A Playwright skill, for the CLI and IDE. The frontend use case links the playwright-interactive skill from OpenAI's skills repository. Its SKILL.md lists real setup costs as of today: it needs the js_repl feature turned on in ~/.codex/config.toml, and for now it asks you to run Codex with --sandbox danger-full-access. Weigh that before you use it, and run it only in a project you trust. OpenAI also marks that repository as deprecated in favor of its plugins repository, so check for a newer version first. The same repo has a simpler playwright skill that drives playwright-cli from the terminal, and the Playwright CLI skill page covers Microsoft's version.
How do you turn a Figma design into code with Codex?
OpenAI's Figma use case uses the Figma plugin from the openai/plugins repository. With it, Codex uses the Figma MCP server to pull structured design context, variables, assets and the exact variant to build. The plugin bundles skills such as figma-design-to-code and figma-code-connect.
The use case's starter prompt tells Codex to start with get_design_context for the exact node or frame, fall back to get_metadata if the response is truncated, run get_screenshot before coding, and translate the Figma output into the repo's own utilities instead of "inventing a parallel system." It then asks for a Playwright comparison against the Figma reference. See the Codex plugins guide for installing plugins.
How do you keep Codex on your design system?
OpenAI's guide is direct about this: "Codex works best when the target repo already has a clear component layer." In an existing codebase it will usually find your components on its own. In a new or unusual stack, tell it which primitives to reuse, where tokens live, and what counts as canonical for buttons, inputs, cards, typography and icons.
Put that in AGENTS.md so every chat starts with it. Here is an example section, composed for this guide rather than taken from OpenAI's docs:
## Frontend rules
- Components live in src/components/ui. Reuse them; do not add new UI libraries.
- Colors, spacing and type come from tokens in src/styles/tokens.css. No hex values in components.
- Every page must work at 375px and 1280px wide.
- After a UI change, open the page in the browser and compare it with the reference before saying it is done.
The AGENTS.md guide for Codex explains where Codex looks for these files.
Which prompts work well for frontend work?
OpenAI's suggested follow-up, for when the first pass misses, is short: attach the current implementation and the reference, then say "This doesn't look right. Make sure to implement something that matches closely the reference," and list what differs. The guide also says to ask Codex to compare against the screenshots, not just confirm the build passes.
These are example prompts written for this guide:
Implement the screen in the attached screenshots (desktop.png, mobile.png) as a new route at /billing. Reuse our existing Card, Table and Button components and the spacing tokens. Open it in the browser at both widths and list any differences from the references before you finish.
@Browser open http://localhost:5173/dashboard. The sidebar overlaps the chart below 900px wide. Reproduce it, fix only the layout CSS, and screenshot the result at 800px and 1280px.
Review src/components/checkout for accessibility: labels, focus order, contrast and keyboard traps. Fix what you can without changing the visual design and list anything that needs a design decision.
For more, see the React prompts, Tailwind CSS prompts and accessibility prompts.
Which skills help Codex with frontend work?
Codex reads skills that follow the open Agent Skills standard, so skills written for other agents work too. The build skills docs say Codex loads repo skills from .agents/skills and personal skills from $HOME/.agents/skills, and you invoke one with $ in the CLI or IDE extension.
| Need | Skill | Notes |
|---|---|---|
| Browser checks | playwright-interactive |
Linked from OpenAI's frontend use case; see setup caveats above |
| Figma to code | Figma plugin | OpenAI's plugins repo |
| Distinctive design | frontend-design | Anthropic's design direction skill |
| UI review rules | web-design-guidelines | Vercel's interface guidelines |
| Components | shadcn | shadcn/ui usage for agents |
| React performance | react-best-practices | Vercel's React and Next.js rules |
| Accessibility | accessibility | Audits and fixes |
The Codex skills guide covers installing and writing your own.
How does Codex compare with Claude Code for frontend?
Both can work from screenshots, edit components and check pages in a browser. Codex's built-in browser lives inside the ChatGPT desktop app, with annotations and style adjustments on the page. Claude Code connects to Chrome or uses the Browser pane in its desktop app. The Claude Code for frontend guide covers that side, and the Codex vs Claude Code comparison goes wider. Since both read Agent Skills, the same design skills work in either.
Where do you keep your frontend prompts and skills?
Prompts like "match this screenshot using our tokens" get reused on every screen, so keep them in one versioned place. Kipt saves prompts and Agent Skills as Markdown in a private GitHub repo you own, with {{name}} blanks for routes or component names, and installs your skills into Codex or Claude Code with npx skills add. To turn a prompt you already use into a skill folder, try the free SKILL.md generator.