"Invalid browser service environment" in Codex: the browser plugin stuck on an old version

You ask Codex on Windows to read or control Chrome. The app opens a window at about:blank, sees no page, and returns Invalid browser service environment. No tab is read, none is controlled, and it happens on both routes: the app's built-in browser and control of the installed Chrome.

The error was reported on 2026-11-05 in openai/codex #59676, on Windows 11 Pro build 26300, AppX app 26.1029.9216.0 and browser plugin at 26.820.60940. As of 2026-11-08 the issue is still open, with no official fix. What exists is a clear diagnosis and a path another report already unblocked.

What does "Invalid browser service environment" mean?

It means the browser process loaded a plugin generation that does not recognize the environment the app handed it. It is a version mismatch between the Codex runtime and the plugin, not a permission problem and not an outdated Chrome extension.

In the #59676 report, the exception is thrown in browser-service.mjs, inside the setup() function, which rejects any environment value the loaded plugin generation does not know. On that machine the app runtime was on 26.1029.70936, the Chrome plugin was on 26.1029.70936, and the browser plugin was stuck at 26.820.60940, an August build.

Why does clearing the plugin cache not fix it?

Because the cache is the consequence, not the cause. The app re-materializes the plugin from the bundled marketplace snapshot, and that snapshot is what is stale.

The report is explicit: after deleting the cache, Codex recreates the same 26.820.60940. While the active marketplace is out of date, wiping the folder just repeats the installation of the wrong generation.

How do you confirm the version mismatch?

With two commands and one file check. The first shows the marketplaces Codex is considering; the second shows what is actually installed.

codex plugin marketplace list --json
codex plugin list --marketplace openai-bundled --json

In the second command, find the browser entry and look at the version and installedPath fields. The marketplace that matters is named openai-bundled, and it is not a Git source: it is a local snapshot, so codex plugin marketplace upgrade does not touch it.

The comparison that closes the diagnosis is between the browser plugin version and the app version. In the #59676 report, the plugin sat at 26.820.60940 while the runtime was already at 26.1029.70936.

Then open %USERPROFILE%\.codex\config.toml and find the NODE_REPL_TRUSTED_SERVICES line. It is a JSON value that points at the file the runtime trusts, and the path carries the version inside it:

NODE_REPL_TRUSTED_SERVICES = '{"browser":"C:/Users/<you>/.codex/plugins/cache/openai-bundled/browser/26.820.60940/scripts/browser-service.mjs","sky":"@oai/sky/service"}'

Notice that in this case the path is consistent with the installed plugin, and the error happens anyway. So the problem is not the path pointing at another version: it is the installed plugin being a generation the current app does not recognize. What is worth checking in the path is whether it actually exists. The table below summarizes what each reading means.

What you see	What it means
codex plugin list shows browser on a version older than the app's	Stale marketplace snapshot. The right plugin exists in the installed package, but it is not the one that got materialized
The NODE_REPL_TRUSTED_SERVICES path points at a version that does not exist under plugins\cache\openai-bundled\browser	Materialization failed. The runtime trusts a file that is not there
The folder %USERPROFILE%\.codex\plugins\cache\openai-bundled does not exist at all	A Windows provisioning failure with a different cause. See the missing cache section
Versions match and the error persists	A different failure. Worth opening an issue with both versions and the app log

If you want a broader diagnostic, codex doctor --json returns checks in machine-readable form, including startup plugin warnings. It does not compare versions for you, but it quickly shows whether the plugin loaded at all.

Which fix unblocks the plugin?

There is no official fix as of 2026-11-08. What exists is a procedure one user tested and documented in another issue for the same mechanism, #47443. There the symptom was a missing module; here it is an invalid environment. The cause is the same: the marketplace snapshot fell behind the installed package.

Warning before you start: this is manual surgery on a cache folder and on files from the Windows package. Back up first, run it with the app closed, and treat it as a last resort. The #47443 report records that no package files and no Windows security settings were changed in the process.

1. Close the Codex app and locate the current snapshot. The path comes from codex plugin marketplace list --json, usually %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled.
2. Rename the old snapshot as a backup. Do not delete it. If the new procedure fails, you are one command away from the previous state.
3. Copy the current marketplace from the installed package. Locate the package folder with Get-AppxPackage *codex* | Select InstallLocation and copy app\resources\plugins\openai-bundled into a staging directory using xcopy /G, as in the original report. Before replacing the snapshot, confirm that every relative path and every file length matches the source.
4. Reinstall the plugin with the supported command. It installs the snapshot version into the expected cache and returns the final version as JSON.

codex plugin add browser@openai-bundled --json

Check the version and installedPath fields in the output. The path must match what appears in NODE_REPL_TRUSTED_SERVICES. If the command says the plugin is already installed, remove it first and add it again:

codex plugin remove browser@openai-bundled --json
codex plugin add browser@openai-bundled --json

Open the app and ask the agent to run await agent.browsers.list(). The list must include the browser backend you use. In the #47443 report, the equivalent test with agent.browsers.get("edge") returned the backend documentation and the open tabs, which confirmed the bind.

What if the cache folder is missing entirely?

Then the problem is different, even though the symptom looks the same. In #46744, config.toml pointed at plugins\cache\openai-bundled\browser\<version>\scripts\browser-service.mjs and the folder was never created. Files from the AppX package are marked as protected, and the copy the app attempts in order to materialize the plugin fails, leaving incomplete openai-bundled.staging-* directories behind.

In that case reinstalling the plugin does not help, because the plugin never reaches the cache. The path is to provision the cache the same way as the procedure above, copying from the installed package, or to wait for the official fix. That issue also lists Browser, Computer Use, and image generation as down from the same materialization failure.

What is not worth trying?

Attempt	Why it does not work
Deleting plugins\cache\openai-bundled	The app recreates the same old version from the stale snapshot
Restarting the app or the machine	The version is decided at materialization, not at startup
codex plugin marketplace upgrade	It upgrades Git marketplaces. openai-bundled is a local snapshot
Reinstalling the plugin without updating the snapshot	It reinstalls exactly the generation that was already there
Updating the app	In the #46744 reports the failure persisted across later versions

How do you keep working without the app browser?

Separate the tasks that need a browser from the ones that do not. Refactoring, testing, builds, reading a repository, and writing code do not depend on the browser plugin and keep working normally in the terminal. For the tasks that do need a browser, an automation MCP on a terminal agent avoids the desktop app provisioning path.