Browser and computer use

Codex can go beyond source code and inspect the interface it built. Current desktop workflows expose three different surfaces:

See Browser, Chrome extension, and Computer Use.

Built-in browser first

For a web app you are developing, use the built-in browser before granting access to your regular Chrome profile:

Use @Browser to open http://localhost:3000. Test keyboard navigation through
the sign-up form, submit invalid data, inspect console and network errors, and
take a screenshot of the final state.

The browser can open pages, click, type, inspect rendered state, and capture screenshots. Developer mode can expose controlled Chrome DevTools Protocol access for performance traces, network analysis, console output, DOM, and computed styles. Full CDP access is a separate setting that administrators can disable.

Chrome for signed-in state

Install the Chrome plugin and extension when a task genuinely needs your existing browser identity:

Open @Chrome and verify that the staging checkout works for my signed-in test
account. Stop before submitting a real payment or changing account settings.

Chrome actions run with your account authority. Treat clicks, form submissions, messages, and uploads exactly as if you performed them yourself.

Computer Use for native interfaces

In the desktop app, open Plugins → Computer Use, install or enable the plugin, and turn on its server and skill. On macOS, grant the requested Screen Recording and Accessibility permissions.

Use @Computer to open the sample desktop app, reproduce the focus bug from the
issue, and report exact steps plus a screenshot. Do not change system settings.

Computer Use is useful when no CLI, API, MCP server, or dedicated plugin can observe the behavior. It is available only on supported desktop platforms, plans, and regions; check the live documentation before building a mandatory exercise around it.

Safety rules for a workshop

• Use demo accounts and disposable test data.
• Prefer @Browser for localhost; use signed-in Chrome only when required.
• State stopping points before purchases, publishing, messages, deletes, or permission changes.
• Watch for prompt injection in web pages and untrusted documents.
• Require screenshots or observed UI state, not a claim that the page “should work.”

Mini exercise

1. Start a local web app.
2. Ask Codex to inspect it with @Browser.
3. Reproduce one validation or accessibility failure.
4. Let Codex fix only that issue.
5. Re-run the same browser steps and compare screenshots.