Computer Use and Browser (Computer Use): Giving Codex Hands

📚 Series Navigation: The previous article [16 Security and Risk Boundaries] clarified the boundary of "how much trouble Codex can cause and where the limits are." This article opens another door—allowing Codex to view your screen, click your desktop applications, and open your browser: to test a native App, reproduce a bug that only appears on the interface, or click buttons for you on websites you have logged into. In all previous chapters, Codex worked strictly in the "files + command line" domain; this is the first time it reaches out to touch graphical user interfaces (GUIs). The next article [18 Comprehensive Guide to config.toml Configurations] will return to the configuration file, twisting all those knobs at once.

⚠️ Experimental features, subject to change. Computer Use, the Chrome extension, and the in-app browser discussed in this article are all iterating rapidly. Any specific entry points, menu names, default behaviors, and hotkeys mentioned below are subject to what you actually see on your screen and the official Codex documentation. Subsequent versions may adjust these.

OpenAI draws a hard geographic red line in its official documentation for Computer Use: upon release, it is available on macOS and Windows, but not in the European Economic Area (EEA), the United Kingdom, or Switzerland. This is not a network connectivity issue, but rather that the feature itself is disabled by region—meaning if you are in London, even using a VPN might not allow you to enable it.

I first noticed this last year when counting pages in the app document directory: the three pages computer-use, browser, and chrome-extension are dedicated to "how Codex interacts with graphical interfaces," which is longer than the sandbox section. OpenAI spending so much ink here shows they believe one thing—an AI that can only read files and run commands will eventually hit a wall when "this task can only be done on an interface."

Here is a wall I actually hit: last year when debugging a small Electron tool, a bug only crashed the app when the window was dragged to a specific width. Running tests in the command line worked fine, and the logs were completely clean. For this kind of "GUI-only" bug, I previously had to drag the window, take screenshots, and describe it to the model. Computer Use is here to tear down this wall—allowing Codex to look at the screen and reproduce it on its own.

This article covers three main topics: the three paths for Codex to touch graphical interfaces (Computer Use, the Chrome extension, and the in-app browser), what each is responsible for, how to enable them, and where the security boundaries lie when operating your "real desktop / real browser."

By reading this article, you will get:

• An explanation of what Computer Use is, when it is appropriate to use it (and when you should not use it)
• A clear distinction between the three paths to touch interfaces: in-app browser (localhost) → Chrome extension (sites with logged-in states) → Computer Use (entire desktop), along with a comparison table
• Steps to enable each of the three paths (which plugins to install, which system permissions to grant, how to call it with @), as well as regional/platform restrictions
• Default behaviors for website access (asking you for every new site by default), how to manage the allowlist / blocklist, and which switch disables prompts permanently
• The risks of operating your "real desktop / real browser" compared to a sandbox, what guardrails the official team provides, and what rules you should follow
• A minimal hands-on exercise you can run with expected results: reading a local page using the in-app browser

---

01 Understand First: What Exactly is Computer Use, and When Should You Use It?

The bottom line: Computer Use = letting Codex "view the screen, and use the mouse and keyboard" like a human to operate graphical interfaces—it can see windows, menus, and buttons on your macOS or Windows system, click them, type text, and navigate menus. It steps in when command-line tools cannot reach and structured integrations (plugins / MCPs) do not exist.

The official docs state its core purpose clearly: use it only when a task "cannot be verified just by looking at files or command output." For example:

• Testing a macOS App, Windows App, iOS simulator flow, or other desktop applications that Codex is helping you write.
• Reproducing a bug that only appears in the graphical interface (like my window-dragging crash example above).
• Modifying application settings that must be changed via UI.
• Finding information in an application or data source for which no plugin is available.
• Running a workflow that spans multiple Apps.

Analogy: Hiring an intern who can "use your computer" instead of a remote colleague who can only send emails. You can only send commands to and receive files from a remote colleague (command line / plugins); he cannot touch your desktop. The Computer Use intern sits at your desk—he uses your mouse and keyboard, sees what is on the screen, and you can watch exactly where he is clicking in real-time. Convenient as it is, he operates on your real desktop, not a test machine in a separate room—which is a key security point discussed later.

Here is a common pitfall that the official documentation repeatedly emphasizes:

For Web applications built locally, use the in-app browser first instead of Computer Use.

Why? Because Computer Use is the "heaviest and slowest" method—it has to take screenshots, calculate coordinates, and move the mouse frame-by-frame. Don't use a sledgehammer to crack a nut when lighter tools can do the job. The correct order is: use plugins / MCPs if available, use browser tools for web pages, and upgrade to Computer Use only when you must touch native desktops, simulators, or interface-less apps. The next section breaks down these three paths.

💡 Summary in one sentence: Computer Use lets Codex view the screen and use the mouse and keyboard to operate the entire desktop. It is the "heaviest" path, reserved for native Apps, interface-only bugs, and plug-in-less data sources; use the in-app browser first for local Web apps, and don't rush to use Computer Use.

---

02 Distinguish the Three Paths: In-app Browser / Chrome Extension / Computer Use

Before connecting, let's clear up a common confusion: Codex has three paths to touch "interfaces," and beginners almost always choose the wrong one. The official documentation dedicates a page to each of these three, showing they are distinct features rather than three names for the same thing.

Analogy: Three modes of transport to get things done in another city. For local short distances (local web pages), walking gets you there quickly without a ticket—this is the in-app browser; to go to an office building you frequently visit where you have an access card (websites where you are logged in), you drive your own car with the card inside—this is the Chrome extension; to go to rural areas with no paved roads (native desktops, apps with no APIs), you rent an off-road SUV that can handle rough terrain—this is Computer Use. All three can "move," but using the wrong one will either get you stuck or cause unnecessary effort.

Let's look at each path's primary domain:

In-app browser—A browser built into the Codex window, sharing the rendering view with you. It is dedicated to: local development servers (localhost), file previews, and public pages that do not require login. It does not touch your Chrome login state, cookies, extensions, or open tabs—making it clean and isolated. Previews and verifications are kept inside Codex without affecting your daily browser. Use it when you want to see the effect after changing front-end code during development.

Chrome extension (Codex Chrome extension)—Use this when the task requires your logged-in browser state. The official docs list typical scenarios: letting Codex read / operate LinkedIn, Salesforce, Gmail, or company internal tools that require logging in. It leverages your real Chrome login state to access everything you have logged into.

Computer Use—As discussed in the previous section, this operates on the entire desktop: native Apps, simulators, and cross-application workflows. It has the widest range but is also the slowest.

Comparing the three paths shows you when to choose each:

Dimension	In-app Browser	Chrome Extension	Computer Use
What it touches	Web pages in Codex's built-in browser	Your real Chrome (with login state)	Entire macOS / Windows desktop
Typical Tasks	localhost, file previews, public pages	LinkedIn / Salesforce / Gmail / internal systems	Native Apps, simulators, cross-app flows
Uses Your Login State?	❌ No, clean and isolated	✅ Yes, uses Chrome's login state	Depends on the specific app
How to call it	@Browser or ask it to "use the browser"	@Chrome	@Computer or @AppName
What to install	Browser plugin	Chrome plugin + Chrome extension	Computer Use plugin
Weight / Speed	Lightest and fastest	Medium	Heaviest and slowest

A simple division of labor: use the in-app browser for local web pages, the Chrome extension for logged-in sites, and Computer Use only when you must touch the desktop. The following sections cover how to enable each.

💡 Summary in one sentence: There are three paths to touch interfaces—in-app browser (localhost / public pages, no login state), Chrome extension (websites you are logged into), and Computer Use (entire desktop); from lightest to heaviest, select the right path before acting to avoid getting stuck or wasting effort.

---

03 Path 1: In-app Browser (The One You Should Use First)

Following the "lightest-to-heaviest" order, let's start with the in-app browser. Its role is simple: you share a viewport with Codex to render pages, specifically for previewing and verifying local Web applications.

Install the Plugin + Open It

First, install the Browser plugin: go to Plugins in Codex, add the Browser plugin, and enable it (specific paths are subject to the GUI).

Second, open the in-app browser. The official documentation offers several ways:

• Clicking it from the toolbar;
• Automatically opening when clicking a URL in the chat;
• Manually entering an address to navigate;
• Using hotkeys—Cmd+Shift+B on macOS, and Ctrl+Shift+B on Windows.

Let Codex Operate the In-app Browser

More than just previewing, you can let Codex directly operate this in-app browser: clicking, typing, viewing rendered states, taking screenshots, downloading page resources, running read-only page inspections in JavaScript, or verifying if a fix is working.

To call it, ask it to "use the browser" in the task, or refer to it directly with @Browser. An official prompt example:

Open http://localhost:3000/settings with the browser, reproduce that layout bug,
and fix only the overflowing controls without touching anything else.

Its "Annotation" Feature

The most valuable aspect of the in-app browser is annotations (comment / annotation)—when a bug is only visible on the rendered page, you can circle it on the element and leave a note. This gives Codex a precise element-level target, which is far clearer than describing it with text.

Official operation tips (subject to change):

• Open Annotation mode, select an element or region, and submit a comment;
• Hold Shift and click in annotation mode to drag-select a region;
• Hold Cmd and click to send the comment immediately.

Once annotated, send a message in the chat telling it to process. A good annotation is specific, for example:

This button overflows on mobile. Keep it on one line if it fits,
otherwise wrap it, but do not change the height of the card.

There is also a more detailed menu—click the config icon on the annotation to adjust fonts, text size, spacing, and colors directly on the interface, previewing the effects in real-time before submitting to Codex. This is much more precise than text descriptions like "make the font a bit larger and the color warmer." What you see is what you get.

Personally, I find annotations extremely effective for "almost there" visual adjustments—last month when styling a pricing page, the tooltip kept covering data points under the cursor. Instead of describing coordinates, I circled the tooltip and wrote "move it within the chart area, don't cover data points," and Codex fixed it on the first try. The key is describing the "visual state" you care about: loading, empty, error, or success.

Keep this isolation boundary in mind, as stated in the official docs:

The in-app browser does not support authentication flows, pages requiring login, your daily browser configuration, cookies, extensions, or open tabs. It is only for opening pages that do not require login.

In other words—it cannot handle websites requiring login; that is the job of the Chrome extension covered next.

💡 Summary in one sentence: The in-app browser is Codex's built-in, isolated browser. Install the Browser plugin and call it with @Browser to preview and verify localhost / public pages; annotations (circling elements + notes) are its most valuable feature; it does not touch login states, leaving those to the Chrome extension.

---

04 Path 2: Chrome Extension (For Sites Requiring Login States)

When the task depends on your logged-in browser state—reading your LinkedIn, updating Salesforce contacts, working in Gmail, or operating internal company systems—it is time for the Chrome extension.

Install via Plugins

The official installation flow goes through plugins. Follow the steps:

1. Open Codex and go to Plugins.
2. Add the Chrome plugin.
3. Follow the setup wizard—it will guide you to install the Codex Chrome extension (from the Chrome Web Store) and approve permissions prompted by Chrome.
4. Open Chrome and confirm that the Codex extension shows Connected.

Installing the extension and accessing the Chrome Web Store might require appropriate network access; follow the Codex setup wizard to avoid installing the wrong extension.

Once installed, open a new Codex thread. Codex will actively suggest using Chrome when tasks require logged-in sites. You can also name it in your prompt:

@Chrome Open Salesforce and update the corresponding accounts based on these call logs.

If Chrome is not running, Codex can open it for you. A convenient detail: Chrome browser tasks run inside Chrome tab groups, grouping tasks from the same thread together so your tab bar doesn't become messy.

Website Access: Asking You for Every New Site by Default

This is the most important default behavior of the Chrome extension (and the in-app browser) to understand—do not assume it can access anything as soon as it is installed:

By default, Codex will ask you before operating on any new website. It prompts for confirmation based on the website host (e.g., example.com).

When prompted, you have three options depending on your risk tolerance:

• Allow in the current conversation only;
• Always allow this host, so it won't ask again in the future;
• Deny access to this website.

Finer controls are available in the Computer Use settings—where you can maintain an allowlist and blocklist:

• Codex will not ask for domains in the allowlist;
• Codex is blocked from using domains in the blocklist;
• Removing a domain from the allowlist means it will ask you again next time; removing it from the blocklist changes it from "blocked" to "ask again."

There are two switches / settings where beginners often slip up:

Setting	Default / Behavior	Pitfall Reminder
Ask for every new site	Enabled by default (will prompt)	This is the first gate; do not rush to turn it off just because it is annoying
Always allow browser content	Once manually enabled, Codex stops prompting confirmations for using websites	Enabling this removes that gate; think twice before turning it on
Browser history	Codex will ask when it wants to access it, and there is no "always allow" option	History may contain sensitive information like internal URLs and search queries; grant access as needed and close it after use

The browser history rule is worth highlighting: the docs state that history access must be authorized per request, with no permanent permission allowed—because history often contains sensitive internal addresses, search queries, and activity trails on logged-in devices. If induced by malicious content on a page, this data could be exfiltrated. Hence, the system deliberately avoids a "once-and-for-all" option.

Troubleshooting Connections

A connection failure is the most common issue when using the Chrome extension. Follow the official troubleshooting sequence (confirm first that the site is not blocked by the blocklist before proceeding):

1. Click the Codex extension icon in the Chrome toolbar to see if it is Connected. If disconnected or prompting for a missing native host, go to Plugins in Codex, remove and re-add the Chrome plugin, and run the wizard again.
2. Go to Plugins in Codex and confirm the Chrome plugin is enabled.
3. Confirm you are using the Chrome profile that has the extension installed—users with multiple profiles often fail here, running tasks in B while the extension is installed in A.
4. Open a new thread to clear thread-level connection states.
5. Restart Chrome and Codex. If it still fails, uninstall the extension, remove and re-add the Chrome plugin, and run the wizard again.
6. If it shows Connected but still does not work, run /feedback to contact support, attaching the thread ID.

Another small pitfall: if Chrome tasks need to upload files from your computer, you must enable "Allow access to file URLs" in the extension details page; otherwise, it cannot access local files. Restart the task after changing this.

💡 Summary in one sentence: Use the Chrome extension for websites requiring logged-in states. Add the Chrome plugin via Plugins, install the extension using the wizard, confirm it is Connected, and call it with @Chrome. It asks you for every new site by default. Manage the allowlist / blocklist in Computer Use settings, and be aware that enabling "always allow browser content" removes the warning gate.

---

05 Path 3: Computer Use (Interacting with the Entire Desktop)

We save the heaviest path for last. Computer Use lets Codex view the screen and use the keyboard/mouse to operate the entire macOS / Windows desktop. Enabling it requires crossing two hurdles—region + system permissions—which are higher than the previous two paths.

Check Region and Platform First

First, let's address the restrictions:

• Platform: Available on macOS and Windows; Linux is not supported (the Codex Desktop App itself does not have a Linux version, as covered in Article 07).
• Region: Not supported in the European Economic Area (EEA), the United Kingdom, or Switzerland at release. If you are physically in these locations, it might fail to open; this is not a bug.

Install the Plugin + Grant System Permissions

First, install the Computer Use plugin: go to Codex settings, open Computer Use, and click Install—make sure it is installed before asking it to operate desktop apps.

Second, grant system permissions, which differ by platform:

On macOS, you must grant two permissions (they will prompt on first use; grant them as instructed):

Permission	Purpose
Screen Recording	Allows Codex to see the target app's interface
Accessibility	Allows Codex to click, type, and navigate

If Codex cannot see or control an application, go to System Settings > Privacy & Security and enable "Screen Recording" and "Accessibility" for the Codex application.

On Windows, there are no system authorization pop-ups, but there is a rule regarding active windows: Computer Use runs on the active desktop, and the target application must remain visible during the task. Furthermore:

On Windows, Computer Use cannot run in the background. While the task is running, Codex will move your mouse cursor, type, and take over the active screen.

Simply put: it takes over your mouse and keyboard when working on Windows, preventing you from using the computer at the same time. To let tasks run while you are away, the official documentation suggests two ways: keeping the device unlocked and connected while monitoring progress on your phone, or running Codex inside a Windows VM so it takes over the VM instead of your main desktop.

How to Call It

Refer to @Computer in your prompt, or call an application directly with @AppName, describing which App, which window, and which flow to run. Two official examples:

Use computer use to open this App, reproduce that onboarding bug,
and fix the minimal code path causing it. Rerun the UI flow after each change.

Open @Chrome and verify if the checkout page still works after the latest change.

Note the second example—@Chrome can either use the Chrome extension (structured, with login states) or let it "visually" operate the browser under the Computer Use context. The official recommendation is: use dedicated plugins / MCPs if available, and use Computer Use only when you need "visual mouse-and-keyboard operations."

Permissions and Approvals: Different from System Permissions

A common point of confusion is that "system permissions" and "application approvals" inside Codex are two separate things:

• System permissions (macOS Screen Recording / Accessibility): Give Codex the ability to see and operate applications.
• Application approvals: Determine which applications you allow Codex to use. It will ask you before using an application in a task; you can select Always allow so it won't ask again. This "always allow" list can be managed and removed in Codex settings under the Computer Use panel.
• File reads, file edits, and shell commands still follow the thread's sandbox and approval settings (from Articles 15 and 16), which are not relaxed just because Computer Use is enabled.

For sensitive or destructive operations, Codex might ask again.

Locked Use (macOS Only, Enable with Caution)

An advanced capability called Locked use is available only on macOS and is disabled by default (you must enable it manually). It solves the issue where you trigger a Codex task from another device but your Mac is locked.

Once enabled, Codex installs an Apple authorization plugin to participate in the macOS login process, temporarily unlocking the Mac during trusted Computer Use sessions while maintaining screen lock protection. The official documentation lists 4 safety guardrails:

• The authorization window is short-lived, valid only for the current unlock attempt.
• Auto-unlock is only open to active Codex sessions.
• Codex covers all monitor screens during the unlock period.
• Any local keyboard / mouse movement immediately locks the screen and pauses auto-unlock.

The official docs make it clear: this is a narrowly tailored feature, not a general backdoor for remote unlock on your Mac. Other Apps and local processes cannot borrow it. Beginners should not enable this until they have a genuine need for "tasks running after the screen locks."

💡 Summary in one sentence: Computer Use operates on the entire desktop and has the highest entry barrier—EEA / UK / Switzerland are not supported, and Linux is excluded; macOS requires "Screen Recording + Accessibility" permissions, while Windows takes over your foreground; system permissions are distinct from application approvals, and file/shell tasks still follow sandbox rules; Locked Use is macOS-exclusive, disabled by default, and narrowly tailored, so beginners should avoid it for now.

---

06 Security: Operating on the "Real Desktop / Real Browser," Not a Sandbox

This section is critical—because Computer Use and the Chrome extension operate on your real desktop and browser where you are logged in, not a disposable sandbox. This is a completely different trust boundary compared to running commands in a sandbox (Article 15). The "convenience-to-risk ratio" mentioned in Article 16 is at its highest here.

Where the Risks Lie

The official docs state: during Computer Use, Codex can view screen contents, take screenshots, and manipulate windows, menus, keyboard inputs, and the clipboard of target applications. Treat "everything it can see" as context it will process. Be aware of two categories of risk:

• Login state equals credentials: It accesses websites without re-authentication; it can reach whatever you have logged into. The official warning is clear:

  Web pages may contain malicious or misleading content, and websites will treat approved clicks, form submissions, and actions under logged-in states as initiated by you.

• Prompt Injection: As covered in Article 16—web page content may hide malicious instructions written for the AI. This risk is highly real when operating browsers / desktops because it reads external content that you do not control.

Guardrails Provided by the System

Fortunately, it is not a free-for-all. Several gates are built-in:

• Asking for every new website (Section 04) is the first gate on the browser side.

• Approving every new application (Section 05) is the first gate on the desktop side; sensitive / destructive operations may prompt again.

• Operations can be interrupted at any time—you can cancel the task or regain control of the computer immediately.

• Certain actions are completely blocked, acting as hard guardrails:

  Computer Use cannot automate terminal applications, nor can it automate Codex itself (which would bypass Codex security policies); it cannot authenticate as administrator, nor can it approve system security and privacy prompts on your computer.

The last point is reassuring—it cannot click the system dialog asking to "grant permissions," keeping security access firmly in your hands.

Rules You Should Follow

Beyond official guardrails, here are some rule-of-thumb practices for operating real desktops / browsers, summarized as a "do's and don'ts" table:

Scenario	❌ What NOT to do	✅ What to do
Assigning tasks	Throwing multiple Apps/flows at it to run concurrently	Assign one clear target application or workflow at a time
Sensitive applications	Leaving online banking or password managers open	Close sensitive applications if the task does not need them
Running on Windows	Trying to use the machine while it takes over the screen	Use a second device / VM, or pause the task before using it
Tasks involving keys	Letting it run unattended	Only run them when you are present to approve step-by-step
"Always allow"	Clicking allow for every prompt just to save time	Only enable it for Apps/sites you truly trust it to use automatically
Accounts/payments/privacy/network settings	Let it click through to completion	Monitor the entire process in person
Clicking the wrong window	Waiting for it to correct itself	Cancel the task immediately

Regarding data: changes made through desktop applications might not appear in the review pane until they are saved to disk and tracked by version control—do not assume no changes were made just because the review pane is empty. Additionally, your ChatGPT data control settings apply to content handled by Codex, including screenshots taken during Computer Use.

Want to use your browser while it works? The official docs suggest a clean workaround—tell Codex to use a different browser, separating it from your daily browser to avoid interference.

The core principle: every click it makes on your desktop / browser is "real"—unlike running commands in a sandbox where you can delete the container and start over, clicking "confirm payment" in a browser is a real payment. The more irreversible or financial the operation is, the more you must keep your hands on the wheel.

💡 Summary in one sentence: Computer Use and the Chrome extension touch your real desktop / browser (non-sandbox), with risks lying in "login states as keys" and "prompt injections on pages." Official guardrails include prompts for each site/app, immediate interruption, and blocking automation of terminal/Codex itself/system dialogs; you must assign one task at a time, close unrelated sensitive apps, and keep financial or irreversible operations under your control.

---

07 Hands-on: Read a Local Page Using the In-app Browser

Practice makes perfect. Here is a minimal hands-on exercise: using the in-app browser (the lightest and safest path) to open a local page and read some text. It does not touch your login states or take over your screen, acting as a check to see "if the path works."

Why practice with the in-app browser? Because it does not require system permissions, does not touch Chrome, and is not restricted by region, making it the lowest-barrier option. The Chrome extension and Computer Use follow the same principles but have more gates.

Step 1: Start a local server

Start a simple static server to give the in-app browser a local URL to open. You can run:

python3 -m http.server 3000

Expected: The terminal displays Serving HTTP on :: port 3000 (http://[::]:3000/) ... or similar, showing the local server is up. Access http://localhost:3000 with your daily browser to verify it opens (it should list files in the current directory).

Step 2: Install and open the in-app browser

Go to Plugins in Codex, and confirm that the Browser plugin is added and enabled. Open the in-app browser using the hotkeys:

• macOS: Cmd+Shift+B
• Windows: Ctrl+Shift+B

✅ Verify: A built-in browser viewport pops up inside the Codex window.

Step 3: Tell Codex to read the page using the in-app browser

Send a read-only instruction that does not touch sensitive accounts:

Use the browser to open http://localhost:3000,
read the filenames listed on the page to me, and take a screenshot.

Expected: You will see the in-app browser navigate to http://localhost:3000. Codex reads the content (the list of filenames in the directory) back to the chat and attaches a screenshot. Seeing it open and return content means the path is working. The first time it accesses a site, it might prompt you to approve using the website (as covered in Section 04); click allow.

Step 4 (Optional): Try annotations

To experience the annotation feature from Section 03, open Annotation mode, circle an element on the page, leave a note (e.g., "this font is too small, make it two sizes larger"), and send a message for Codex to process. Expected: It targets the circled element precisely without you having to describe its location.

Running the first three steps completes the flow of "install Browser plugin → open in-app browser → read local page." Whether you use the in-app browser for other tasks later, or upgrade to the Chrome extension / Computer Use, the process is the same: install plugin → grant permissions/approve → call with @ → watch it run. The only difference is that the heavier options have more gates.

💡 Summary in one sentence: The hands-on exercise has three steps—start a local server, open the in-app browser (Cmd/Ctrl+Shift+B), and send a read-only command to see it fetch the page; this is the safest and lightest path, and running it prepares you for the other paths which follow the same pattern with more safety gates.

---

08 Summary

This article connects Codex to graphical interfaces—from manipulating files and command lines to opening browsers, clicking desktop apps, and reproducing bugs that only appear on interfaces. More importantly, you learned that there are three paths to touch interfaces, and you must select the correct one.

Let's review the key points:

Task	Key Concept
Understand Computer Use	Let Codex view the screen and use the keyboard/mouse to operate the desktop; this is the heaviest path, use the in-app browser first for local Web apps
Distinguish the three paths	In-app browser (localhost) → Chrome extension (logged-in sites) → Computer Use (entire desktop), from lightest to heaviest
Open In-app Browser	Install Browser plugin, call with @Browser, open with Cmd/Ctrl+Shift+B; annotations are its key feature
Open Chrome Extension	Add Chrome plugin in Plugins, install the extension, call with @Chrome; asks you for every new site by default
Open Computer Use	Install Computer Use plugin; macOS requires "Screen Recording + Accessibility" permissions, Windows takes over the screen; EEA / UK / Switzerland and Linux are not supported
Keep Secure	You operate the real desktop / browser: run one task at a time, restrict website/app scopes, and keep financial/irreversible steps under your control

You should now be able to: explain what the three paths are and when to use each; open the in-app browser to read local pages; install the Chrome extension and Computer Use and understand their region/platform restrictions; and identify the risks of operating real desktops / browsers and how to manage them. This connection is a major step for Codex—allowing it to look at screens and interact with interfaces for you.

The relationship between these three paths is summarized in the diagram below:

This diagram outlines the process: "task needs interface → what kind of interface → which path to take → specific characteristics." Refer to it next time you are unsure which path to use.

💡 Summary in one sentence: The three paths range from light to heavy—the in-app browser handles local and public pages, the Chrome extension manages logged-in websites, and Computer Use controls the entire desktop. With greater power comes greater risk, and the core rule is: actions on real desktops / browsers are "real"; keep financial and irreversible operations under your control.

---

The next article [18 Comprehensive Guide to config.toml Configurations]—in this article you installed three plugins and configured permissions and allowlists; does it feel like settings are scattered and hard to track? Fortunately, Codex groups most of its behavioral knobs in a single file—config.toml. The next article breaks down these knobs: models, sandboxes, approvals, MCPs... what each switch controls, their defaults, and whether they require restarts. A quick thought: in this article, we let Codex operate by installing plugins and granting permissions; how do you think we save preferences like "which model to use by default" or "how permissive it should be by default" so they are active from startup?

---

Recommended Reading

• Subscribing and Billing
• Command Line CLI Guide
• Troubleshooting Common Issues: Installation, Login, and File Writing