How to Choose Between the Codex CLI, Chrome Extension, and Computer Use¶

What to decide before giving Codex screen control¶

For / Key Points

Audience: Developers deciding when Codex should stay in the CLI, use the in-app browser, use Chrome, or operate a GUI through Computer Use.

Key Points:

Separate CLI-friendly work from work that deserves screen-level control
Identify when signed-in Chrome state, GUI state, or cross-app work changes the tool choice
Check the minimal Windows/Mac setup, website access rules, and troubleshooting path

Imagine a Salesforce campaign screen where only the leads table breaks in production. CI passes. The API returns normal data. The bug only becomes visible after opening the signed-in Chrome profile, applying the campaign filter, and checking horizontal scroll plus modal overlap.

That is the kind of task where Chrome integration or Computer Use can help. Code edits, test runs, log searches, and API checks should usually stay in the CLI because they are repeatable, reviewable, and easier to audit.

This article is not mainly a setup guide. It is a decision framework for choosing between the CLI, in-app browser, Chrome extension, and Computer Use before giving an AI agent screen access.

First Remove Work That Belongs In The CLI¶

This section answers: which work should not be handed to screen control at all?

The default is simple: if a task can be completed through commands, files, tests, or APIs, keep it in the CLI. Test runs, linting, file edits, log searches, and JSON API checks are faster and more auditable there.

Computer Use becomes useful when the target is not a file or command output but visible screen state. Examples include whether a button is reachable, whether a modal overlaps the form, or what a signed-in internal SaaS screen actually shows.

Decision point	CLI works best	Computer Use / Chrome works best
Target	Code, logs, tests, APIs	Screens, signed-in sites, GUI apps
Repeatability	High, through command reruns	Depends on screen and login state
Review	Git diff and stdout are clear	Needs screenshots, outcome review, and permission checks
Reason to use	Speed, certainty, auditability	Access to state the CLI cannot see

Computer Use is not a CLI replacement. It is a way to recover the GUI work that remains outside the command line.

Choose The Right Surface¶

This section answers: once screen-level work is justified, which surface should Codex use?

The default split is straightforward. Use the in-app browser for localhost, Chrome for signed-in browser state, and Computer Use for GUI-level desktop work.

Surface	Best for	Avoid for
In-app browser	Localhost, file-backed previews, public pages without sign-in	Auth flows, cookies, existing tabs, Chrome extensions
Chrome extension	Gmail, Salesforce, LinkedIn, internal tools, signed-in websites	Local preview work that does not need Chrome state
Computer Use	GUI-only state, cross-app workflows, normal app UIs	Repeatable data work that has an API or plugin

OpenAI's docs point local development servers and public pages that do not require sign-in toward the in-app browser first.² The Chrome extension is for tasks that need signed-in browser state.¹ Computer Use is for cases where Codex needs to see, click, and type in apps.³

That distinction matters. Chrome integration is powerful, but it should not become the default for every visual check.

Practical Use Cases Where GUI Control Pays Off¶

This section answers: where does GUI control create real value in daily work?

Computer Use and Chrome integration are most useful when the task depends on GUI state, signed-in browser state, or movement across multiple apps. OpenAI's use case page describes Computer Use as useful for normal app UIs and workflows that jump between apps or windows.⁶

Pattern	Why it helps	Why the CLI is weak
Signed-in admin screens	Codex can inspect CRM, SaaS, or internal dashboards in the real account state	Auth, cookies, and tenant state are hard to reproduce from the CLI
GUI-only bug reproduction	Hover, drag/drop, focus, modals, and layout overlap can be checked directly	DOM or tests may miss the visual failure
Browser-extension-dependent checks	Password managers, enterprise extensions, or translation extensions stay in the Chrome profile	The in-app browser does not use your normal Chrome profile or extensions
Visual review of artifacts	PDFs, slides, and spreadsheets can be checked as rendered artifacts	File structure does not always reveal visual breakage
Internal tool drafting	Slack, Notion, CRM, or hiring tools can be compared across screens before drafting	API integrations may be missing or too costly to set up

1. Reproduce a signed-in admin screen bug¶

The report says a CRM lead table breaks only for one production campaign. Call the API from the CLI -> confirm the data is normal -> use @Chrome to open the campaign with a test account -> apply the filter -> inspect column width, horizontal scroll, and modal overlap -> form a DOM/CSS hypothesis -> patch in the CLI -> re-check the same URL.

Here Chrome owns the signed-in browser state, while the CLI owns the code change and test loop. That split is usually faster than forcing everything into one surface.

2. Check flows that depend on a Chrome profile or extension¶

Some issues only reproduce with enterprise SSO, a password manager, a translation extension, or a test-only Chrome extension. Have Codex open the target site -> inspect the post-SSO page -> note whether an extension-injected UI appears -> stop before submit or permission changes -> report only the visible symptoms.

The in-app browser is weaker for this work. It is good for local checks, but it does not rely on the normal Chrome profile, existing tabs, or installed extensions.²

3. Review generated artifacts visually, then return to the CLI¶

A script generates a PDF or slide deck. Generate the file in the CLI -> use Computer Use to open the viewer or PowerPoint -> check clipped text, overflowing tables, and overlapping chart legends -> return the page or slide number plus symptom -> fix the template in the CLI.

The file structure can be valid while the rendered artifact is unusable. In this pattern, Computer Use is not the primary implementer; it is the visual reviewer.

A practical prompt should narrow the action boundary first.

@Chrome open the staging CRM and inspect the leads list for campaign "Spring-2026".

Goal:
- Check whether table width or horizontal scrolling breaks after filtering

Allowed actions:
- View pages, change filters, and inspect visible UI only
- Do not submit, delete, change permissions, or share externally

Output:
- Reproduction steps
- Visible symptom
- Likely DOM/CSS hypothesis
- Candidate files to fix from the CLI

If npm test, rg, git diff, or a JSON API call answers the question, Computer Use is probably unnecessary. That boundary keeps permissions from expanding by habit.

Keep Permissions Narrow And Verify Outcomes¶

This section answers: how much should you allow Chrome or Computer Use to access?

By default, Codex asks before it interacts with each new website. The prompt is based on the website host, and you can allow the site for the current chat, always allow the host, or decline it.¹

A practical policy looks like this:

Allow localhost and staging hosts when the task needs them
Keep production admin pages chat-scoped instead of always allowed
Do not always allow payment, authentication, or security settings pages
Put suspicious or unnecessary external sites on the blocklist
Keep submit, purchase, permission, and security actions under human review

Browser history deserves extra caution. OpenAI's docs note that history may include internal URLs, search terms, and activity from signed-in Chrome sessions on other devices.¹ Codex asks when it wants to use browser history, and history does not have an always-allow option.¹

Think of Chrome integration as lending Codex signed-in browser state for one job. A dedicated Chrome profile and a clean starting browser state make the work easier to audit.

Minimal Setup After The Decision¶

This section answers: after choosing the surface, where do you configure it?

Before using Chrome integration, make sure Codex app can run a normal local or worktree thread. The Codex app is available for macOS and Windows, and Local threads run on your computer after you select a project folder.⁴⁵ The Windows app supports the core app workflows, including worktrees, automations, Git functionality, the in-app browser, artifact previews, plugins, and skills.⁷

The minimum baseline is:

You are signed in to Codex app with a ChatGPT account or an OpenAI API key
The target project is added to Codex app
Your local web app can start its development server
You can review the resulting Git diff

Do not start with permissions. Start with the task boundary: which URL, which logged-in account, and which actions Codex is allowed to take.

In the current Codex app UI, manage Chrome from Settings > Settings > Computer Use. The Google Chrome row shows the connection, and Manage lets you review its state and permissions.

The official docs also describe the plugin setup flow: open Codex, go to Plugins, add the Chrome plugin, follow the guided setup, install or connect the Chrome extension, and approve Chrome's permission prompts.¹ In practice, use Plugins for first-time setup and Computer Use settings for day-to-day management.

After setup, open Chrome and confirm that the Codex extension shows Connected. Start a new Codex thread so the connection state is clean. When you want to be explicit, invoke Chrome in the prompt with @Chrome.

@Chrome open the internal dashboard, check the failed deploy page,
and summarize only the visible error messages.

If Chrome is not open, Codex can open it. Chrome browser tasks run in Chrome tab groups, which helps keep a thread's work separate from your normal browsing.¹

Computer Use is a separate capability from the Chrome extension. It lets Codex see, click, and type in graphical interfaces when screen-level operation is the task.³

Open Settings > Settings > Computer Use to review Computer Use-related items. On macOS, grant the permissions that match what you want Codex to do:³

Screen Recording, so Codex can see the target app
Accessibility, so Codex can click, type, and navigate

On Windows, the Codex app itself is supported and includes plugins and the in-app browser.⁷ If your Windows environment shows Computer Use settings, apply the same narrow task boundary; the OS permission prompts and names differ from macOS.

Use @Computer or @AppName and keep the target narrow.

Open @Chrome and verify the checkout page still works.
Do not change account settings or submit any payment form.

Computer Use can affect apps and system state outside the project workspace. Review prompts based on the app being used, not on momentum.

Troubleshoot Chrome Connection Issues¶

This section answers: where should you look first when Chrome does not connect?

If Chrome does not connect, check state before reinstalling everything. OpenAI's troubleshooting order starts with extension connection state, plugin state, and Chrome profile matching.¹

Use this order:

Open the Codex extension from Chrome's toolbar or extensions menu and confirm it says Connected
In Settings > Settings > Computer Use, confirm Google Chrome is connected
Make sure you are using the same Chrome profile where the Codex extension is installed
Start a new Codex thread and retry the Chrome task
Restart Chrome and Codex, then remove and re-add the Chrome connection if needed

For Chrome tasks that upload files from your computer, enable Allow access to file URLs in the Chrome extension details page.¹ This is easy to miss when a task touches local HTML files or file-backed previews.

Summary¶

Codex Chrome integration and Computer Use are not replacements for CLI work. The safer default is to use them only when the task truly needs screen state, signed-in browser state, or cross-app GUI work.

Use the in-app browser for local web apps, the Chrome extension for signed-in sites, and Computer Use for GUI-level desktop work. That split gives Codex useful visual reach without turning browser access into a broad permission blanket.

The next step is team policy. Decide which hosts can be allowed, which actions require human review, and when Codex should use a dedicated browser profile. Chrome integration is not just a convenience feature; it is an operating model for letting an AI agent see logged-in screens.