Computer Use plugin becomes unavailable after Codex Desktop restart

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #26296
• #26377
• #25758
• #26387

Powered by Codex Action

3 weeks later and nobody has been assigned to the bug yet. This should be a high priority bug.

3 weeks later and nobody has been assigned to the bug yet. This should be a high priority bug.

yeah, but I have asked codex to fix it by itself. this bug is gone

what process did it use to fix it?

People should NOT have to do this.

what process did it use to fix it? People should NOT have to do this.

I just tell codex this issue, ask to fix it

I did this and it worked.

<img width="1294" height="789" alt="Image" src="https://github.com/user-attachments/assets/8db762f0-160a-4e1d-a7c6-11cd0496eecf" />

<img width="1115" height="669" alt="Image" src="https://github.com/user-attachments/assets/55d000ab-5554-4ccd-8d91-d62168cdc4c5" />

I did this and it worked. <img alt="Image" width="1294" height="789" src="https://private-user-images.githubusercontent.com/1555174/615521651-8db762f0-160a-4e1d-a7c6-11cd0496eecf.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODI4ODY5NTUsIm5iZiI6MTc4Mjg4NjY1NSwicGF0aCI6Ii8xNTU1MTc0LzYxNTUyMTY1MS04ZGI3NjJmMC0xNjBhLTRlMWQtYTdjNi0xMWNkMDQ5NmVlY2YucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcwMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MDFUMDYxNzM1WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9M2Y1ODFjZWQ5MTFmNzhmNGU4ZDFjOWM3Yzk1NTY2Nzg1NTk1YjQ4YTM1NzA3MzBkY2FmZDkxMzBmZDRmNjZkNyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.cXoOmwII348gEoTZigNVqJHGAe5E6W9hXJkpxw88S70"> <img alt="Image" width="1115" height="669" src="https://private-user-images.githubusercontent.com/1555174/615521861-55d000ab-5554-4ccd-8d91-d62168cdc4c5.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODI4ODY5NTUsIm5iZiI6MTc4Mjg4NjY1NSwicGF0aCI6Ii8xNTU1MTc0LzYxNTUyMTg2MS01NWQwMDBhYi01NTU0LTRjY2QtOGQ5MS1kNjIxNjhjZGM0YzUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcwMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MDFUMDYxNzM1WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MjUxZWM4NjZjYjM1NTM2NzcwZjBlYWQ1NGM5YTU1OTZlNzUxOGFmOTgzZGI0ZmMwMGRlYmUwMGI0MTc1OWZlNyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.KMskVVYHlJA9IRWhg5Krx7xXH69hhN-8hr2GbvdVIS4">

congratulations, same as I did with codex.

the problem is that it breaks when you update Codex! So this is a temporary workaround that must be reapplied

I asked Codex to summarize the fix for the developers:

The advice to Codex should be: make plugin/native-host repair part of the update flow, not something the user has to rediscover manually.

Suggested wording for the bug report:

Recommended permanent fix

Codex Desktop should automatically regenerate and validate Browser / Computer Use native-host configuration after every desktop app update on Windows.

Specifically, the update/startup flow should:

1. Detect when the running Codex package version differs from any version recorded in:

%USERPROFILE%\.codex\chrome-native-hosts-v2.json

1. Re-run the bundled native-host/plugin installer for the current app version.

1. Ensure this file exists after install:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host-config.json

1. Remove or ignore stale native-host entries that point at old WindowsApps package paths, for example older OpenAI.Codex_... directories that no longer match the running app.

1. Surface a clear repair action in Settings if validation fails, rather than only showing Computer Use plugins unavailable.

1. On startup, validate that the native-host config points to the current Codex runtime, CLI, Node runtime, and extension host paths.

A concise bug-report paragraph:

Please make the Windows Codex Desktop updater/startup path idempotently repair Browser and Computer Use native-host configuration. After recent updates, Computer Use becomes unavailable because %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host-config.json is missing and %USERPROFILE%\.codex\chrome-native-hosts-v2.json still contains stale C:\Program Files\WindowsApps\OpenAI.Codex_... paths from previous versions. Manually rerunning the bundled native-host installer fixes it, so Codex should run that repair automatically whenever the app version changes, prune stale entries, and expose a one-click “Repair Computer Use / Browser plugins” action if validation fails.

That gets the core point across: the installer already knows how to fix it; the bug is that update/startup does not run or validate that repair reliably.

I can reproduce the same startup reconciliation race on macOS after updating Codex Desktop, but this time it affects the bundled Browser plugin itself.

Environment

• macOS
• Bundled Browser version: 26.707.72221
• The Browser plugin remained enabled in ~/.codex/config.toml, but the UI/CLI reported it as not installed after the update/restart.

Sanitized startup sequence

At startup, Codex first wrote a reduced bundled marketplace that did not contain Browser:

bundled_plugins_runtime_marketplace_written pluginCount=6 pluginNames=["sites","chrome","computer-use","record-and-replay","latex","visualize"]
bundled_plugin_uninstall_requested pluginId=browser@openai-bundled reason=not_in_bundled_marketplace_plugin_names
bundled_plugin_uninstall_succeeded pluginId=browser@openai-bundled

A few seconds later it wrote the complete marketplace, now including Browser:

bundled_plugins_runtime_marketplace_written pluginCount=7 pluginNames=["sites","browser","chrome","computer-use","record-and-replay","latex","visualize"]
bundled_plugin_install_skipped_missing pluginName=browser

So this appears to be the same two-stage startup race described in this issue:

1. A temporary/incomplete marketplace excludes Browser.
2. Reconciliation uninstalls Browser with not_in_bundled_marketplace_plugin_names.
3. The complete marketplace arrives shortly afterward.
4. Browser is not restored because installation is skipped as missing.

The Browser package is present in the current Codex application/cache, and the newer Browser client no longer has the previous Cannot redefine property: process initialization problem. Manual installation immediately restores it:

/Applications/ChatGPT.app/Contents/Resources/codex plugin add browser@openai-bundled

After that, Browser is again listed as installed and enabled at version 26.707.72221.

This suggests the bug is not limited to Computer Use or native-host repair: the bundled marketplace reconciliation itself can remove Browser during startup/update. It would be safer to avoid uninstalling bundled plugins until the marketplace/feature availability state is final, or to automatically reinstall every plugin removed during the transient state once the full marketplace is available.

Additional Windows reproduction and packaged-code evidence for the same bundled-plugin startup race.

Environment

• Windows 11 x64
• Codex App 26.707.12708.0
• Bundled app-server 0.144.5
• Clean-room reinstall still reproduced the behavior

44 ms availability flip

On startup, the official Desktop log recorded:

09:34:29.250 bundled_plugins_reconcile_started reason=startup
09:34:29.251 browser_use_availability_resolved available=false browserPane=false reason=browser-pane-disabled
09:34:29.295 browser_use_availability_resolved available=true browserPane=true reason=available

The false-to-true transition took only 44 ms.

A previous launch then recorded:

bundled_plugin_uninstall_requested
pluginId=browser@openai-bundled
reason=not_in_bundled_marketplace_plugin_names
plugin_uninstall_succeeded

The following launch recorded:

bundled_plugin_install_requested pluginName=browser reason=missing
plugin_install_succeeded pluginName=browser

This reproduces the issue without stale pre-reinstall plugin state.

Packaged-code failure boundary

Inspection of the shipped ASAR indicates:

• Renderer browser availability treats the browser-pane value as a boolean, while the other asynchronous browser/config gates expose loading state.
• During the initial unresolved pane state, Renderer emits electron-desktop-features-changed with browserPane=false and logs browser-pane-disabled.
• Main receives every feature snapshot through setDesktopFeatureAvailability and starts bundled-plugin reconciliation.
• The marketplace reconciler derives the currently eligible bundled-plugin names from that snapshot.
• Its uninstall path immediately removes installed bundled plugins absent from the current name set with reason not_in_bundled_marketplace_plugin_names.

The destructive action therefore consumes a transient feature snapshot before the Renderer state has stabilized. The later true snapshot can reinstall Browser, but the needless uninstall/install cycle still mutates plugin state, invalidates skills/plugin queries, and adds startup work.

Suggested fix

• Represent browserPane as loading | enabled | disabled rather than defaulting unresolved state to false.
• Do not run destructive bundled-plugin reconciliation until all eligibility inputs are resolved.
• Add a monotonically increasing feature-snapshot revision and discard stale queued reconciliations.
• Require a stable/confirmed marketplace snapshot before uninstalling a bundled plugin; a single transient omission should not be authoritative.
• Reconcile an already installed bundled plugin idempotently after startup instead of uninstalling and reinstalling it.

This appears to be the same lifecycle bug as the temporary incomplete marketplace described in this issue, now reproduced on Windows specifically for Browser.

Reproduced on macOS in ChatGPT Desktop 26.715.31925 (build 5551) on two consecutive launches. Browser availability changed from false to true 70–125 ms after startup. The first reconciliation still materialized a marketplace without Browser and uninstalled it with not_in_bundled_marketplace_plugin_names; the queued pass then materialized Browser and reinstalled it. This confirms the same startup race is still present in the current build, even when the recovery pass succeeds. Full timeline: #34069.