Skip to content

Computer Use plugin becomes unavailable after Codex Desktop restart #26429

Open
Open
Computer Use plugin becomes unavailable after Codex Desktop restart#26429
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useskillsIssues related to skills

Description

@LockyJohn
LockyJohn
opened on Jun 4, 2026

Bug Report: Computer Use disappears after Codex restart

Summary

On Codex Desktop for macOS, the Computer Use plugin repeatedly becomes unavailable after restarting Codex. The "Computer Control" settings page shows:

Computer Use 插件不可用

Chrome and Browser may recover automatically, but Computer Use remains missing from the UI until manually reinstalled with:

codex plugin add computer-use@openai-bundled

Environment

  • App: Codex Desktop
  • Bundle identifier: com.openai.codex
  • Version: 26.601.21317
  • Bundle version: 3511
  • Platform: macOS arm64
  • Locale: zh-Hans-CN / zh-CN
  • Codex Doctor: install consistent, state databases healthy, auth configured, network connected

Expected Behavior

After restarting Codex, the bundled Computer Use plugin should remain installed/enabled, and the Computer Control settings page should show the normal controls for:

  • Any app / Computer Use
  • Google Chrome
  • Lock screen operation

Actual Behavior

After restarting Codex:

  • The Computer Control page shows Computer Use 插件不可用.
  • The UI does not show the normal Computer Use / Any App row.
  • The issue returns even after reinstalling Codex by overwriting /Applications/Codex.app.
  • Manual plugin reinstall restores the underlying plugin state:
computer-use@openai-bundled  installed, enabled  1.0.799

But after the next restart, the UI can again show Computer Use as unavailable.

Reproduction Steps

  1. Install or reinstall Codex Desktop 26.601.21317.

  2. Ensure Computer Use is installed and enabled:

    codex plugin list --marketplace openai-bundled

  3. Quit Codex completely.

  4. Reopen Codex.

  5. Open Settings -> Computer Control.

  6. Observe that Computer Use is shown as unavailable.

Relevant Log Timeline

Latest startup log shows Codex first creates a runtime bundled marketplace containing only latex, then uninstalls the other bundled plugins:

2026-06-04T16:55:45.095Z info [BundledPluginsMarketplace] bundled_plugins_runtime_marketplace_written pluginCount=1 pluginNames=["latex"]
2026-06-04T16:55:45.098Z info [BundledPluginsMarketplace] bundled_plugin_uninstall_requested pluginId=browser@openai-bundled reason=not_in_bundled_marketplace_plugin_names
2026-06-04T16:55:45.127Z info [BundledPluginsMarketplace] bundled_plugin_uninstall_requested pluginId=chrome@openai-bundled reason=not_in_bundled_marketplace_plugin_names
2026-06-04T16:55:45.153Z info [BundledPluginsMarketplace] bundled_plugin_uninstall_requested pluginId=computer-use@openai-bundled reason=not_in_bundled_marketplace_plugin_names

A few seconds later, Codex writes the correct marketplace containing all bundled plugins:

2026-06-04T16:55:47.727Z info [BundledPluginsMarketplace] bundled_plugins_runtime_marketplace_written pluginCount=4 pluginNames=["browser","chrome","computer-use","latex"]

Codex then reinstalls Browser and Chrome, but skips Computer Use:

2026-06-04T16:55:47.759Z info [BundledPluginsMarketplace] bundled_plugin_install_requested pluginName=browser reason=missing
2026-06-04T16:55:47.857Z info [BundledPluginsMarketplace] bundled_plugin_install_requested pluginName=chrome reason=missing
2026-06-04T16:55:47.983Z info [BundledPluginsMarketplace] bundled_plugin_install_skipped_missing pluginName=computer-use

The Computer Control UI appears to read the plugin/remote-control state during this transient missing period:

2026-06-04T16:55:48.447Z info [AppServerConnection] response_routed method=plugin/list
2026-06-04T16:55:48.624Z info [AppServerConnection] response_routed method=plugin/list
2026-06-04T16:55:48.710Z info [AppServerConnection] response_routed method=plugin/list

Current Diagnosis

This appears to be a Codex Desktop bundled plugin startup race or lifecycle bug:

  1. Startup reconciliation writes a temporary bundled marketplace with only latex.
  2. That causes browser, chrome, and computer-use to be uninstalled as not_in_bundled_marketplace_plugin_names.
  3. The full marketplace is written shortly after.
  4. Browser and Chrome are reinstalled automatically.
  5. Computer Use is skipped with bundled_plugin_install_skipped_missing.
  6. The Computer Control page caches or displays the transient missing state and reports Computer Use 插件不可用.

Workaround

Manual reinstall restores the plugin:

codex plugin add computer-use@openai-bundled

After this, the CLI shows:

computer-use@openai-bundled  installed, enabled  1.0.799

But this does not fully solve the startup/UI race after restart.

Additional Notes

  • The Codex application bundle does contain the Computer Use plugin:

    /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use

  • The generated runtime marketplace also contains computer-use after startup completes:

    ~/.codex/.tmp/bundled-marketplaces/openai-bundled/.agents/plugins/marketplace.json

  • The installed Computer Use app passes codesign verification when manually installed.

  • codex doctor --summary --ascii reports install consistency and healthy state databases.

Request

Please fix bundled plugin startup reconciliation so Computer Use is not uninstalled during the temporary marketplace state, or ensure it is reinstalled/refreshed like Browser and Chrome after the full bundled marketplace is written.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    computer-use
    skillsIssues related to skills
    on Jun 4, 2026

  2. github-actions commented on Jun 4, 2026

    @github-actions
    github-actionsBot
    on Jun 4, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. skirsch commented on Jun 28, 2026

    @skirsch
    skirsch
    on Jun 28, 2026

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

  4. LockyJohn commented on Jun 29, 2026

    @LockyJohn
    LockyJohn
    on Jun 29, 2026
    Author

    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

  5. skirsch commented on Jun 30, 2026

    @skirsch
    skirsch
    on Jun 30, 2026

    what process did it use to fix it?

    People should NOT have to do this.

  6. LockyJohn commented on Jun 30, 2026

    @LockyJohn
    LockyJohn
    on Jun 30, 2026
    Author

    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

  7. skirsch commented on Jul 1, 2026

    @skirsch
    skirsch
    on Jul 1, 2026

    I did this and it worked.

    Image Image

  8. LockyJohn commented on Jul 1, 2026

    @LockyJohn
    LockyJohn
    on Jul 1, 2026
    Author

    I did this and it worked.

    Image Image

    congratulations, same as I did with codex.

  9. skirsch commented on Jul 3, 2026

    @skirsch
    skirsch
    on Jul 3, 2026

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

  10. skirsch commented on Jul 3, 2026

    @skirsch
    skirsch
    on Jul 3, 2026

    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.

    2. 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.

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

    3. 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.

  11. chuankris commented on Jul 14, 2026

    @chuankris
    chuankris
    on Jul 14, 2026 – with ChatGPT Codex Connector

    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.

  12. NOirBRight commented on Jul 16, 2026

    @NOirBRight
    NOirBRight
    on Jul 16, 2026

    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.

  13. MlDenis
    marked Browser plugin is uninstalled and reinstalled during app startup #34069 as a duplicate of this issue on Jul 18, 2026

  14. MlDenis commented on Jul 18, 2026

    @MlDenis
    MlDenis
    on Jul 18, 2026

    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.

  15. SwordFourteen commented on Aug 1, 2026

    @SwordFourteen
    SwordFourteen
    on Aug 1, 2026 – with ChatGPT Codex Connector

    Follow-up: Windows 26.727.6591 reproduced the same destructive latex-only startup race

    This is a new Windows reproduction on a current Store build. It is especially notable because the marketplace materialization logged success, yet the generated marketplace temporarily collapsed from six plugins to only latex. The reconciler then treated that transient one-plugin snapshot as authoritative and uninstalled every other bundled plugin.

    Environment

    • Surface: Codex Desktop from Microsoft Store / MSIX
    • Package: OpenAI.Codex 26.727.6591.0
    • Bundled/local CLI: codex-cli 0.146.0-alpha.9.2
    • OS: Windows 11 Pro x64, build 10.0.26200
    • RAM: 31.82 GiB

    Local usernames, workspace names, absolute user paths, thread identifiers, and complete logs are intentionally omitted.

    Sanitized UTC timeline

    At startup, several remote curated-plugin catalog requests also failed with -32603. I am including that correlation but am not claiming it caused the local bundled-marketplace defect.

    04:23:26.538 plugin_marketplace_folder_write_succeeded
               marketplaceName=openai-bundled
               pluginCountBeforeWrite=6
               pluginCountAfterWrite=1

04:23:26.538 bundled_plugins_runtime_marketplace_written
               pluginCount=1
               pluginNames=["latex"]

04:23:26.545 bundled_plugin_uninstall_requested
               pluginId=sites@openai-bundled
               reason=not_in_bundled_marketplace_plugin_names
04:23:26.574 bundled_plugin_uninstall_requested
               pluginId=browser@openai-bundled
               reason=not_in_bundled_marketplace_plugin_names
04:23:26.795 bundled_plugin_uninstall_requested
               pluginId=chrome@openai-bundled
               reason=not_in_bundled_marketplace_plugin_names
04:23:26.960 bundled_plugin_uninstall_requested
               pluginId=computer-use@openai-bundled
               reason=not_in_bundled_marketplace_plugin_names
04:23:26.975 bundled_plugin_uninstall_requested
               pluginId=visualize@openai-bundled
               reason=not_in_bundled_marketplace_plugin_names

04:23:26.989 plugin_marketplace_sync_completed
               pluginCount=1
               pluginsInstalledAfterWrite=0

    About ten minutes later, without a manual plugin repair, the same packaged source path produced the complete marketplace and Codex reinstalled the five plugins:

    04:33:25.497 plugin_marketplace_folder_write_succeeded
               pluginCountBeforeWrite=1
               pluginCountAfterWrite=6

04:33:30.642 plugin_install_succeeded pluginName=sites
04:33:33.280 plugin_install_succeeded pluginName=browser
04:33:33.537 plugin_install_succeeded pluginName=chrome
04:33:35.051 plugin_install_succeeded pluginName=computer-use
04:33:35.074 plugin_install_succeeded pluginName=visualize

04:33:35.074 plugin_marketplace_sync_completed
               pluginCount=6
               pluginsInstalledAfterWrite=5

    codex plugin list --json now shows all five restored plugins installed and enabled. Therefore the machine is currently self-recovered, but there was a real ten-minute destructive uninstall/reinstall interval in which tools and related settings disappeared.

    Configuration-side observation

    The user-level config.toml was atomically replaced immediately after the recovery pass (both creation and last-write timestamps reset at approximately 04:33:36Z). The current file still contains the enabled entries for the restored plugins, so I cannot prove that unrelated user settings were deleted. However, plugin reconciliation is clearly mutating/replacing the shared config during this unstable period, which makes the transient uninstall externally visible as settings/features disappearing.

    Why this strengthens the existing report

    • This reproduces on Windows and a newer 26.727 package.
    • The incomplete snapshot lasted about ten minutes rather than milliseconds.
    • Five bundled plugins were removed together, not only Computer Use or Browser.
    • The write was logged as plugin_marketplace_folder_write_succeeded; there was no copyfile failure to make the snapshot obviously invalid.
    • The same package source later yielded all six plugins, strongly indicating a startup/update availability race or inconsistent source snapshot.

    Requested safeguards

    1. Never perform the uninstall phase when a bundled marketplace abruptly collapses from a previously valid set (for example, 6 -> 1) until the source snapshot has been retried and confirmed stable.
    2. Treat a latex-only snapshot as provisional when the last-known-good bundled marketplace contained Browser/Chrome/Computer Use/Sites/Visualize.
    3. Keep and reuse the last-known-good plugin-name set when materialization, feature availability, or remote catalog state is unresolved.
    4. Make the reconcile transaction fail-safe: stage and validate the full marketplace, then update plugin state/config only after validation succeeds.
    5. Preserve a real pre-write config backup and expose a diagnostic/repair action if the sync removes and later reinstalls plugins.
    6. Add a regression test that feeds the reconciler a transient 6 -> 1 -> 6 sequence and asserts that no installed plugin is uninstalled.

    This looks closely related to the fail-destructive behavior reported in #35472, but the trigger here is different because the partial marketplace write was reported as successful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useskillsIssues related to skills

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions