Codex can finish a front-end change with green tests and a clean build, then leave you with a broken page. CSS overflow, a loading state that never clears, a modal under the wrong layer, or a button pushed below a mobile viewport simply will not show up in the terminal.
When the bug lives on the page, the useful next step is to open the page. Browser can run the local or public site, click through the flow, see what actually rendered, and then go back to the code.[1][2][5] If the page is clearly wrong but the reason is buried in requests, console output, DOM state or runtime behaviour, Developer mode can dig into that layer.[4][5]
Native apps, simulators and system settings sit outside that browser surface, so Computer Use covers a different class of problem.[1][3][6] Memory is separate again: it is there to stop later tasks from having to rediscover the same stable repository context every time.[2][7]
The easiest way to choose between them is to ask what state Codex actually needs to inspect.
Find where the bug lives
If the job is reading fields, updating a known status or creating something through a stable schema, use the structured interface you already have. An API, plugin or MCP server gives Codex explicit actions and leaves a much cleaner trail to review. OpenAI’s Computer Use guidance makes the same recommendation for repeatable data access.[6]
A rendered UI is different. If you need to know whether a modal covers the call-to-action at 390 pixels wide, an API response is beside the point. Open Browser and look at the page. If the page reproduces the failure but you suspect a bad request, runtime exception, DOM state or CSS rule, that is when Developer mode becomes useful.[4][5]
Desktop software follows the same practical rule. There is no reason to make an agent click through menus just to read a value that MCP already exposes. But if the problem is “the spinner never disappears after Save”, the visible flow is part of what you need to verify, so Computer Use makes sense.[6]
Figure 1 | Choose the narrowest interface that can actually observe the claim.
These tools are sometimes drawn as a progression from API to Browser to Computer Use. That makes the choice look harder than it is. A visual bug can go straight to Browser. A structured field update should stay structured. Use the surface that can actually show you the state the claim depends on.
Make Browser replay the same front-end flow
Suppose a failed sign-in shows an error banner that pushes the Submit button below the fold on a small mobile viewport.
Codex can read the component and stylesheet and come up with a plausible fix. That still leaves one question unanswered: what does the page look like after the change? The in-app Browser can open the local development server, reproduce the failed sign-in state, click and type through the flow, inspect the page, attach feedback to an element or region, and then repeat the same check after the code changes.[1][2][5]
change code
→ run or check the local server
→ open the affected route
→ reproduce the target UI state
→ inspect the rendered result
→ change the smallest relevant code path
→ reload and run the same UI flow againTests and builds still belong in the loop. They just answer different questions. A passing test tells you about the behaviour that test covers. A successful build tells you the project can produce its output. Neither one tells you whether the button is visible on a 390-pixel viewport.
Once the page reproduces the bug, there is little point guessing at CSS forever. Developer mode can inspect network traffic, console output, runtime errors, DOM, applied styles and performance behaviour through controlled Chrome DevTools Protocol access.[4][5] Full CDP access reaches more sensitive browser internals, so Codex asks for explicit approval before it uses that level of access.[5]
If all you need is a framework document, use web search. Browser is useful when the page state itself matters, not simply because the task contains a URL.
Move to Computer Use when the problem leaves the browser
A macOS or Windows application, simulator or native settings screen is outside the in-app Browser. If there is no structured integration that exposes the state you need, Computer Use can see the screen, click, type and run the GUI flow directly.[1][3][6]
That does not make GUI automation the default. If the application already exposes the operation through a plugin or MCP server, keep the clean path. Use Computer Use when the visible behaviour is what you are trying to check.[6]
On Windows, Computer Use works in the foreground and moves the pointer and types while it runs.[3] Anyone trying to use the same desktop session at the same time will get in its way, and vice versa. That is not an intelligence problem; it is simply what happens when two operators share one GUI.
The prompt should shrink as the surface gets broader. “Run this onboarding flow, stop at the first failure, fix the relevant code, then replay the same flow” is something you can review. “Look around my computer and fix whatever seems relevant” is not.
Browser content is also untrusted context. Letting Codex interact with a site does not turn text on that page into trusted instructions or approve every action that follows.[5] Computer Use can reach application and system state outside the project workspace, so naming the app, window, flow and stop condition matters.
Sandbox and approval controls still cover file, shell and network execution.[8] Screen Recording, Accessibility and application access are additional operating-system permissions for Computer Use; granting them does not quietly remove the other boundaries.[6]
Let Memory save the boring context, not the evidence
Repositories accumulate a lot of small, stable context: which package manager they use, how the usual workflow runs, repository conventions, technology choices and preferred output shape. If later tasks keep needing the same background, Memory can carry some of it forward.[2][4][7]
The existing Thread is enough when you are simply continuing the same piece of work. Memory starts to help when a different task begins later and should not have to rediscover all of that stable context from scratch.[2][7]
Rules that must always apply still need a durable home. OpenAI’s Memories guidance recommends AGENTS.md or checked-in documentation for required team instructions and keeps Memory as a recall layer.[7] Evidence stays outside both. If you need to know why a deployment failed or what a command actually returned, open the log, file, issue, diff or command output.
Figure 2 | Memory can help recall, but it does not replace rules or evidence.
If Memory says yesterday’s deployment was “probably the migration”, treat that as a hint and open the deployment log. If it merely saves the next task from rediscovering that the repository normally uses pnpm, that is already useful.
Browser and Computer Use give Codex access to more state around the code, but the verification can stay very ordinary: open the page, inspect the runtime, replay the desktop flow. Memory saves repetition. Rules and evidence still belong in places you can inspect directly.
References
- OpenAI, Codex for (almost) everything, 16 April 2026. https://openai.com/index/codex-for-almost-everything/
- OpenAI, ChatGPT & Codex changelog, 16 April 2026 entry. https://developers.openai.com/codex/changelog
- OpenAI, ChatGPT & Codex changelog, 29 May 2026 entry, Computer Use on Windows. https://developers.openai.com/codex/changelog
- OpenAI, ChatGPT & Codex changelog, 11 and 16 June 2026 entries, Browser Developer mode and Memories. https://developers.openai.com/codex/changelog
- OpenAI, Browser, living documentation. https://learn.chatgpt.com/docs/browser
- OpenAI, Computer Use, living documentation. https://learn.chatgpt.com/docs/computer-use
- OpenAI, Memories, living documentation. https://learn.chatgpt.com/docs/customization/memories
- OpenAI, Running Codex safely at OpenAI, 8 May 2026. https://openai.com/index/running-codex-safely/