Windows/Edge: Chrome plugin update leaves locked host, partial cache, stale app-server manifest, and an uninstallable plugin

Open 💬 4 comments Opened Jul 13, 2026 by isCopyman

Environment

  • Windows: 10.0.26200.8457
  • Microsoft Edge: 150.0.4078.48
  • Codex AppX: 26.707.8168.0
  • Codex CLI: 0.144.0-alpha.4
  • Chrome plugin before update: 26.623.81905
  • Chrome plugin reported after update: 26.707.61608
  • Browser: Microsoft Edge with the Codex Chrome Extension installed and enabled

Summary

When Codex updates while the Codex Chrome Extension is enabled in Edge, Edge keeps launching the plugin's extension-host.exe. The process holds files inside the versioned plugin cache. The update can then leave a partially copied plugin directory while Codex reports the new version as installed and enabled. The plugin UI may also be unable to uninstall the plugin.

In this reproduction, four pieces of state diverged:

  1. Installed-plugin state reported 26.707.61608.
  2. The native messaging manifest still launched 26.623.81905.
  3. The latest junction still targeted 26.623.81905.
  4. chrome-native-hosts-v2.json still referenced a removed AppX resources directory from 26.707.3748.0, while the installed AppX was 26.707.8168.0.

Reproduction and evidence

  1. Keep Microsoft Edge running with the Codex Chrome Extension enabled.
  2. Update Codex while Edge continues to launch extension-host.exe from the old versioned plugin cache.
  3. After the update:
  • Codex reports the new plugin as installed and enabled.
  • The cache can be incomplete. A clean source contained 375 files, but the newly installed cache contained only 342 files and was missing both docs/ and .codex-plugin/plugin.json.
  • The native messaging manifest still points to the old versioned extension-host.exe.
  • The plugin UI cannot reliably uninstall the plugin.
  1. Browser communication becomes partially functional:
  • Codex could enumerate 273 open Edge tabs.
  • Claiming/controlling a specific HTTPS tab timed out.
  1. After a CLI remove/add cycle, the cache was again incomplete because the extension host was relaunched during installation.
  2. The extension then showed:
Unable to start ChatGPT
Codex app-server manifest entry is missing required path resourcesPath
  1. chrome-native-hosts-v2.json did contain a resourcesPath, but it pointed to an AppX directory that no longer existed:
...OpenAI.Codex_26.707.3748.0...\app\resources

The currently installed package was:

OpenAI.Codex_26.707.8168.0

Expected behavior

  • Codex should stop or detach the running native host before replacing plugin files.
  • A plugin version should become active only after its complete cache has been staged and validated.
  • Installed-plugin state, latest, the native messaging manifest, and chrome-native-hosts-v2.json should be updated as one recoverable transaction.
  • On startup, Codex should detect a missing or stale resourcesPath and regenerate the app-server/native-host entry automatically.
  • Uninstall should work even if the native host is running: stop the owned process, remove state, and report an actionable error if cleanup fails.

Suggested improvements

  1. Stage into a temporary version directory, validate required files, then atomically rename/switch latest.
  2. Before update/remove, identify and stop only the extension-host processes owned by that plugin cache.
  3. Repoint the native messaging manifest to a stable latest path before deleting an old version.
  4. Refresh the AppX resourcesPath after every desktop update and validate that it exists.
  5. Add startup self-healing for mismatched plugin version, host version, junction target, and app-server manifest.
  6. Add a UI repair action that performs the supported stop/reinstall/re-register workflow and preserves a rollback copy.

Comparison

On the same machine, the user's comparable Claude browser integration has not exhibited this update-time lock, partial-install, or stale-manifest failure. This suggests Codex could improve lifecycle coordination and atomicity rather than requiring users to disable the Edge extension before every desktop update.

Temporary recovery used for diagnosis

  • Back up plugin/config/native-host state.
  • Disable or stop the running extension host.
  • Restore a complete plugin cache from the bundled source.
  • Reinstall the plugin through Codex's plugin command.
  • Rebuild stale app-server/native-host registration on the next Codex startup.

The workaround is fragile; the product should self-heal without manual cache or manifest intervention.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗