How to Choose Between Codex @Computer, @Chrome, and @Browser

Codex can now operate a computer, but it offers three fundamentally different interfaces—@Computer, @Chrome, and @Browser—each with its own trigger word and scope. The article first presents a concise table summarizing the task requirements, recommended surface, and trigger word.

@Computer: Full‑desktop control (slow)

Computer Use lets Codex see the screen, move the mouse, type, and use the clipboard on macOS or Windows, enabling interaction with any native app that lacks an API. The visual loop (screenshot + computer‑vision) makes it inherently slow, but it can automate tasks that would otherwise require manual clicks, such as handling Amazon refunds or searching a local Zotero library for high‑impact papers. Installation requires adding the Computer Use plugin and granting macOS screen‑recording and accessibility permissions. Triggering is done by writing @Computer in the prompt. Limitations include inability to run terminal commands, no access on Windows when running in the background, and a large trust boundary—users should limit its scope to a single app and monitor any actions involving payments or password changes.

@Chrome: Leverage an already‑logged‑in Chrome (fast)

The Chrome extension gives Codex the exact Chrome instance you are logged into, preserving cookies, tabs, and authentication state. It is ideal for SaaS platforms like Gmail, LinkedIn, Salesforce, X, or internal dashboards that require a logged‑in session. Installation involves adding the Chrome extension via the Codex Plugins page and approving the requested Chrome permissions; the surface becomes active when @Chrome appears in the prompt. Compared to @Computer, it supports tab grouping and multi‑tab coordination, allowing Codex to read one tab while acting on another. Example use cases include editing a Strudel Composer page directly or summarizing recent X posts without re‑authenticating.

@Browser: Isolated built‑in browser (secure, dev‑friendly)

The built‑in browser runs inside the Codex conversation, isolated from your regular browser’s cookies, extensions, and login state. It is best for local development servers, public pages, or visual bug reproduction where no authentication is needed. Installation is done by enabling the Browser plugin in Codex; triggering uses @Browser or the shortcut Cmd+Shift+B (Ctrl+Shift+B on Windows). It supports a tight feedback loop: Codex edits code, refreshes the page, captures screenshots, and iterates. An annotation mode lets users click or select page elements and add comments (e.g., “increase spacing”), which Codex receives along with element coordinates to apply changes. A hidden Developer mode exposes the Chrome DevTools Protocol for JS profiling, console logs, and network inspection, though users must be aware of data‑risk implications. The surface is unsuitable for actions requiring login or passkeys; those should fall back to @Chrome.

Appshots: Quick visual reference

Appshots capture the frontmost window on macOS, sending a screenshot and any extractable text to the current Codex dialog. It provides a lightweight way to point Codex at a specific UI element without handing over full control. Only macOS Codex app supports this feature.

Prioritizing surfaces

Manually choosing a surface for every task can be tedious. The author proposes a priority rule that Codex can follow automatically:

# Choose operation surface priority
1. If a plugin or MCP can handle the task, use it (most precise, easy to audit)
2. If the task needs a logged‑in browser, use @Chrome
3. For local dev servers, public pages, or no‑login tasks, use @Browser
4. Only when the above cannot accomplish the goal, fall back to @Computer
5. Pause for manual confirmation before any send, submit, purchase, or publish action

Overall, the three surfaces complement each other: @Browser for isolated, fast web interactions; @Chrome for authenticated web workflows; and @Computer for any desktop app lacking an API, albeit with slower performance and higher trust considerations.