Codex Browser Not Working: Two Recovery Cases

The page was visible, but Codex could not control the browser. Two problems on the same computer—a missing browser connection and a stale error page—required different recovery steps. This article explains the order of checks and what actually recovered.

Built-in browser, Chrome integration, and web search

Asking Codex to “look it up in the browser” does not always use the same mechanism. Identifying which feature is failing, and what it cannot do, helps avoid unnecessary setting changes.

OpenAI’s official browser documentation says Codex in the desktop app can open the built-in browser, click, type, and inspect pages. It does not say the CLI or IDE extension itself has a built-in browser. The first distinction is where you are using Codex.

The built-in browser has a separate profile from your usual browser. Seeing that the Chrome extension is installed does not establish that control of the built-in browser is connected. Conversely, a working built-in browser does not automatically share existing Chrome tabs. OpenAI’s explanation of the browser and its profile

We prioritized the built-in browser in this investigation and used Chrome to check a separate connection route. We avoided treating page display, browser connection, and operations on an individual site as a single “working or not working” result.

The page opens, but Codex cannot find the browser

The investigation began when Codex started reporting that it could no longer perform browser operations that had worked before. The browser was enabled in the app’s settings, and Chrome showed its extension as installed. Pages could also actually be opened in the built-in browser.

However, the control interface’s inventory could retrieve neither the built-in browser nor Chrome. The only visible target was for a separate MCP Apps surface. The screen visible to the user did not match the control targets available to Codex.

To confirm recovery, we needed to test Codex’s ability to get the tab, read its content, and use links, as well as check that the page was displayed.

Three symptoms to distinguish first

A connection problem like this case needs different checks from a problem affecting only one site. First identify how far the operation gets.

Make the test more specific than “fix the browser”: ask it to open a public page → read a heading → click a visible link → go back. This avoids confusing successful web search with successful browser clicks.

A separate chat where reloading alone fixed the problem

In another development chat, a “This site can’t be reached” page left over from a stopped local server remained in the tab. Even after the server recovered, Codex’s attempt to get the tab was rejected because the URL format was not allowed.

The actual URL reported by the normal tab inventory used the data: format, containing HTML directly. When the user reloaded the same tab normally, the actual URL returned to HTTP, and Codex could read the headings and buttons. No restart of the whole app or permission change was needed.

This differs from a browser connection missing from the inventory. What was verified in that chat was content reading only, not entering the game or controlling the game itself. The internal cause of previously recorded connection-route errors also remains undetermined.

What we changed before recovery

On this computer, the actual Codex home data was already at D:\CodexHome. The default %USERPROFILE%\.codex was a junction to drive D, but the user- and machine-scoped CODEX_HOME variables were unset.

OpenAI documents CODEX_HOME as the root for settings, authentication, logs, sessions, skills, and related state. Here we used it to test directly specifying the existing actual path on drive D. It is not documented as a dedicated browser-repair switch. OpenAI’s environment variable specification

1. We stopped the app and related Codex processes. After confirming with the user that work in other chats had finished, we backed up the data while those processes were stopped.
2. We copied the home and other data, then checked the contents. We compared file counts, sizes, and modification times for about 68.6GB across 445,279 files, and also compared hashes for 144 important files.
3. We specified the actual path on drive D for a single launch. After fully quitting the same app version, we launched it and confirmed that the shell and generated control configuration referenced drive D.
4. We tested the built-in browser and Chrome separately. Both could be retrieved, and page reading and link operations succeeded.
5. We also checked normal startup. After approval, we set the user environment variable. A new app instance launched from the taskbar used the same references and passed the same operations.

The important point in this sequence is that we did not move the app itself to another drive first. Browser recovery was confirmed before the app move. A separate failure occurred during that later move, so this case does not support using Windows’ app move feature as a browser fix.

We also did not delete the junction or manually rewrite MCP configuration. We read the references in the configuration generated after startup to check that they matched the intended state. The difference between the home and the app itself is explained in our record of moving from drive C to another drive.

Operations used to confirm recovery

After recovery, we did more than check that the browser appeared in the inventory: we controlled public pages. These checks did not require the user to log in, make a purchase, or upload a file.

We did not retain an inventory of existing private Chrome tabs as article evidence. A newly created test tab was sufficient to confirm recovery. Investigating the browser does not require collecting open email or internal company sites.

We also checked saved state. Selected items, including 2 pinned chats, 18 pinned projects, and 63 local projects, matched the backup. The CLI login-status check completed successfully as well. Recovery did not require rebuilding history or signing in again.

An app restart is different from a PC restart. We checked the former, but deferred checks after a PC restart and future app updates until a convenient time for the user. These results cover immediate recovery and normal app startup.

Actions to avoid at the start

Deleting app data or browser profiles before separating a browser connection problem from a site or storage-location problem can lose logins and settings and remove evidence for comparison. We did not clear all browser data or reinstall the app to recover in this case.

Restoring old browser skills was not our standard remedy either. On the investigated computer, their absence was part of the move to unified Computer Use. A missing old file alone is not enough to identify it as the cause of a failure.

We did not use undocumented internal settings, patch the app’s code, or replace executables. Changing versions might appear to restore functionality, but it would no longer be a before-and-after comparison on the same version, as in this case.

Nor did we need to progressively relax security settings when the necessary permissions for the built-in browser and Chrome were already enabled. Permission to control a site is separate from whether its content should be trusted. Choose a recovery-test page without sensitive information or consequential actions.

Information to keep if it still fails

For support requests or further investigation, a record of how far each operation gets is more useful than a generic “it does not work.” In this case, the important before-and-after difference was that pages could be displayed, control targets could not be retrieved, and after recovery even link navigation worked.

• The app version, and whether you are using the desktop app, CLI, or IDE.
• Whether the symptom affects the built-in browser, Chrome, or both.
• Whether you can open the page manually, whether Codex can read it, and whether it can click.
• Whether it affects only one site or also public pages that require no login.
• Whether you fully quit and launched a new instance, and whether you use another drive or a custom home setting.
• The time of the failure and the actual error message. Exclude raw logs containing secrets.

When checking the home location, distinguish the shell’s $env:CODEX_HOME from the Windows user-scoped setting and the value used by the running app. Users who do not use a custom storage location do not need to imitate this case by pointing to an empty folder on drive D.

Symptoms such as being unable to open history or failing only when sending are not necessarily browser-control problems. Depending on the message displayed, you can also consult our existing article, Codex thread not found and checking history.

An order of checks based on this case

First check where you are using Codex and which browser is involved. If an error page remains after a server has recovered, reload that tab normally. Then test display, reading, and clicking separately on a public page. If there is no browser connection at all, save your work and consider fully quitting and restarting the app. On computers with a custom home migration, it can also be useful to check the referenced location.

The combination that worked on this computer was directly specifying the actual path of the already-existing home on drive D and starting the app after a full quit. We can report that recovery occurred, but cannot say the junction was the sole cause. Checking reversible changes one at a time is a more workable approach than treating app moves or data deletion as universal fixes.

Frequently asked questions

If I can see the page, can Codex control it?

On this computer, the page was visible but could not be retrieved as a control target. Check content reading and link clicking as well.

Will installing the Chrome extension fix the built-in browser?

The built-in browser and Chrome integration use separate routes. Check which is failing. We tested each separately in this case too.

Will setting CODEX_HOME always fix it?

We did not establish that. On this computer, we specified the actual path and fully quit and restarted the app together, after which it recovered. That does not justify recommending a home migration first on computers whose storage location has not changed.

Do I need to move the app to drive D for it to recover?

The browser recovered before the app itself was moved. Moving a Windows app is separate from repairing browser control.