Codex Desktop plugins disappear after restart; Chrome native host manifest is not created and computer-use MCP is not attached

Summary

Codex Desktop plugins for chrome@openai-bundled / Chrome extension and computer-use@openai-bundled repeatedly become unavailable after restart or after a short period of time.

The state can temporarily look fixed after reinstalling the bundled plugins, but the Chrome native messaging host manifest is not created, @chrome remains unavailable, and computer-use may show as enabled in codex mcp list while the current Codex thread does not expose mcp__computer_use tools.

I installed Codex via the official OpenAI website and have repeated the install/repair flow several times. It works temporarily for minutes/hours, then disappears again.

Environment

OS: macOS
App: Codex Desktop, installed from the official OpenAI website
Browser: Google Chrome
Plugins involved:
- browser@openai-bundled
- chrome@openai-bundled
- computer-use@openai-bundled

Expected behavior

After installing/enabling the bundled plugins:

codex plugin list should keep browser, chrome, and computer-use installed and enabled after restart.
codex mcp list should keep computer-use and node_repl enabled.

Chrome native host manifest should exist at:

~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json

@chrome should be callable through the Chrome extension.
@computer-use should be callable from a Codex thread.

Actual behavior

Observed behavior:

browser@openai-bundled works.
chrome@openai-bundled and computer-use@openai-bundled may appear installed/enabled after reinstall, but the state is unstable.

Chrome extension is installed/enabled in Chrome, but the native messaging host manifest is missing:

~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json
exists: false
correct: false

@chrome runtime check fails with:
```
Browser is not available: extension
```
codex mcp list can show computer-use enabled, but the current running thread still does not expose mcp__computer_use tools.
Previously, ~/.codex/config.toml was repeatedly rewritten with an old stale path under ~/.codex/computer-use/.../SkyComputerUseClient.

Checks already performed

Commands/checks used:

codex plugin list
codex mcp list
codex doctor --summary
node /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/chrome/scripts/check-native-host-manifest.js --json

Observed stable/partial state after repair attempt:

browser@openai-bundled: installed, enabled
chrome@openai-bundled: installed, enabled
computer-use@openai-bundled: installed, enabled

codex mcp list:
computer-use: enabled
node_repl: enabled

codex doctor --summary:
17 ok · 1 idle · 0 warn · 0 fail

But the blocker remains:

Chrome native host manifest missing
@chrome: Browser is not available: extension
current thread: no mcp__computer_use tools exposed

Important constraint

I did not manually create the Chrome native host manifest because the bundled Chrome plugin/skill appears to require using the official plugin setup/repair flow rather than manually synthesizing app-managed native host files.

Reproduction pattern

Install/enable chrome@openai-bundled and computer-use@openai-bundled.
Verify codex plugin list and codex mcp list.
Restart Codex and/or wait a few minutes/hours.
@chrome becomes unavailable or remains unavailable because the native host manifest is missing.
computer-use may be enabled in MCP config but not attached as callable tools in the active thread.
In some attempts, stale config paths under ~/.codex/computer-use/... reappear.

Related issues

This looks related to:

Additional debug export

I have a full local debug export with timeline, command outputs, config evidence, and raw redacted session JSONL:

codex-plugin-debug-full-export-2026-06-01.md

It is about 7.5 MB and has been scanned for obvious token/API-key patterns, but it still contains local paths and detailed app state, so I can attach or share a sanitized copy if useful.

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

Codex App overwrites bundled plugin config/cache and removes Computer Use/Browser plugins #25758
Bundled marketplace under .tmp is repeatedly overwritten with incomplete contents, causing Chrome plugin to fail loading #25780
[Bug] Windows Codex Desktop: Computer Use plugin missing from UI and native pipe fails with missing-helper-path #25795
Computer Use native pipe only initializes when the bundled marketplace is (re)written; every normal app restart leaves it "helper paths unavailable" #25665

Powered by Codex Action

Adding another data point from a macOS 26.5 machine. This looks related to the Computer Use / Browser plugin failures, but the local evidence points to a sandboxed trust-evaluation problem rather than the Codex Computer Use.app bundle actually being damaged.

Environment, with private machine/user paths redacted:

macOS 26.5, Darwin 25.5.0, arm64
Codex App 26.601.20914, bundle version 3497
Bundled Computer Use app path: <Codex.app>/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app

Observed symptom:

When Codex invokes Computer Use through tools, macOS shows:
- "Codex Computer Use.app" is damaged and can't be opened. You should move it to the Trash.
The same app can be opened normally outside the Codex tools path.

What I checked:

In a normal/non-sandboxed macOS shell, the app and its helpers validate successfully:

Codex Computer Use.app: valid on disk
Codex Computer Use.app: satisfies its Designated Requirement
Codex Computer Use.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)

The same was true for the main executable and bundled helper apps, including:

SkyComputerUseService: accepted
Codex Computer Use Installer.app: accepted
SkyComputerUseClient.app: accepted
CUALockScreenGuardian.app: accepted

A direct LaunchServices open also succeeded:

open -n <Codex Computer Use.app>

and the SkyComputerUseService process started. No new CoreServicesUIAgent / syspolicyd damaged/rejected log entries appeared after that direct open.

In the Codex tool sandbox, the exact same validation commands fail differently:

Codex Computer Use.app: invalid signature (code or signature have been modified)
spctl: internal error in Code Signing subsystem

Even an Apple system app fails in that sandboxed context:

/System/Applications/TextEdit.app: CSSMERR_TP_NOT_TRUSTED

and keychain lookup is broken there:

security list-keychains
security: SecKeychainCopySearchList: One or more parameters passed to a function were not valid.

Running the same checks outside the Codex tool sandbox immediately succeeds:

/System/Applications/TextEdit.app: valid on disk
/System/Applications/TextEdit.app: satisfies its Designated Requirement

security list-keychains
    <user login keychain>
    /Library/Keychains/System.keychain

Conclusion:

The damaged-app dialog appears to be a false Gatekeeper/code-signing failure triggered by the Codex tools sandbox / Computer Use launch context. The bundled app itself is signed and notarized correctly in the normal macOS trust context. Reinstalling or removing quarantine attributes is unlikely to fix this specific failure mode, because com.apple.quarantine was not present and normal spctl/codesign checks pass.

A likely area to inspect is how Codex launches or validates bundled plugins from the tool sandbox, especially whether that sandbox loses access to the normal keychain/trust evaluation context on macOS 26.5.

Adding a fresh verification run from June 3, 2026.

Current live state on the same macOS Codex Desktop environment:

At the start of the run, codex plugin list showed:
- browser@openai-bundled: installed, enabled
- chrome@openai-bundled: not installed
- computer-use@openai-bundled: not installed
Re-running the supported CLI install path succeeded:
- codex plugin add chrome@openai-bundled
- codex plugin add computer-use@openai-bundled
After reinstall, codex plugin list showed all three installed/enabled.
codex mcp list showed:
- computer-use: enabled, Auth: Unsupported
- node_repl: enabled, Auth: Unsupported
- supabase: enabled, OAuth
codex doctor --summary with TERM=xterm-256color returned: 17 ok · 1 idle · 1 notes · 0 warn · 0 fail.

Chrome-specific checks:

Google Chrome is installed and running.
The Codex Chrome Extension is installed and enabled in the selected Default Chrome profile.
Native host manifest is still missing:

/Users/cocogoat/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json
exists: false
correct: false

The in-app Browser backend works (iab opened https://example.com/ and read title Example Domain).
The Chrome extension backend still fails:

agent.browsers.get("extension") -> Error: Browser is not available: extension

Computer Use-specific checks:

computer-use appears enabled in codex mcp list after reinstall.
Tool discovery in the current Codex thread still does not expose mcp__computer_use action tools.
The bundled MCP process starts and responds to newline-delimited JSON-RPC initialize:

{
  "serverInfo": {
    "name": "Computer Use",
    "version": "d10a51766bb4d162ef1eed308e86a0f8f3816fb860896cb92c18e6de998142af"
  },
  "capabilities": {
    "tools": {
      "listChanged": false
    }
  }
}

However, after notifications/initialized, a tools/list request did not return within 10 seconds, and no stderr was emitted.

This adds one more data point that the issue is not just plugin install status: the Browser backend works, Chrome fails specifically on missing native-host wiring, and Computer Use can initialize as an MCP process while still not becoming a usable tool surface in the active Codex thread.

Adding another macOS data point from a fresh Mac migration / restart cycle. This overlaps with the restart persistence problem, but the current build and observed state are slightly different from the earlier comments.

Environment:

macOS 26.5.1, arm64
Codex App 26.601.21317, bundle version 3511
Bundled Codex CLI: codex-cli 0.136.0-alpha.2
openai-bundled marketplace source: <home>/.codex/.tmp/bundled-marketplaces/openai-bundled

Observed behavior:

After fully quitting and reopening Codex Desktop, the user observed that all bundled plugins disappeared from the Codex UI / active tool surface, including Chrome.
After restarting Codex Desktop two more times, the app reached a partial state where Browser/Chrome appeared usable again, but Computer Use remained missing.
A manual repair earlier in the same session had restored [plugins."computer-use@openai-bundled"] and copied the plugin cache back. After the next Codex restart, Codex rewrote the config/cache and removed Computer Use again.

Current post-restart CLI state:

Marketplace `openai-bundled`
<home>/.codex/.tmp/bundled-marketplaces/openai-bundled/.agents/plugins/marketplace.json

PLUGIN                       STATUS              VERSION       PATH
browser@openai-bundled       installed, enabled  26.601.21317  <home>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/browser
chrome@openai-bundled        installed, enabled  26.601.21317  <home>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/chrome
computer-use@openai-bundled  not installed                     <home>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/computer-use
latex@openai-bundled         not installed                     <home>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/latex

Current config.toml / cache state immediately after restart:

config.toml mtime: 2026-06-04 13:15:50 CST
browser@openai-bundled       present in config: true
chrome@openai-bundled        present in config: true
computer-use@openai-bundled  present in config: false

<home>/.codex/plugins/cache/openai-bundled/browser        exists: true
<home>/.codex/plugins/cache/openai-bundled/chrome         exists: true
<home>/.codex/plugins/cache/openai-bundled/computer-use   exists: false

<home>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/browser       exists: true
<home>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/chrome        exists: true
<home>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/computer-use  exists: true

The generated runtime marketplace JSON still contains browser, chrome, computer-use, and latex, but the installed plugin state/cache is reconciled down to Browser/Chrome only. This makes the manual Computer Use install/config repair non-durable across restart.

The Chrome part is slightly different: after multiple restarts, codex plugin list reports chrome@openai-bundled as installed/enabled, but the user initially saw no Chrome plugin in the Codex UI/tool surface immediately after launching Codex. That suggests there may be two related layers here:

plugin install/cache reconciliation, which removes Computer Use from config/cache;
UI/session/tool hydration, where Chrome may be installed according to CLI state but not immediately visible/attached in the active Codex session after launch.

This does not look like missing bundled files: the active marketplace source still contains the computer-use plugin directory and manifest.

@computer

After every Codex restart, typing @computer shows “Adding computer use...”.
After that, the top-right status says Computer Use is installed.
This indicates the plugin can be added lazily in the current session, but its attached/installed state is not restored on startup.

Possible fix/workaround that just fixed mine on Windows. Not official, so back up first.

My failure was not only the browser extension. The local bundled marketplace was broken. In my case codex plugin list failed with:

marketplace root does not contain a supported manifest

What fixed it:

Update the PATH CLI:

npm install -g @openai/codex@latest
codex --version
codex doctor --summary
Back up these before changing anything:

%USERPROFILE%.codex\config.toml
%USERPROFILE%.codex\plugins\bundled-marketplaces\openai-bundled
Remove the broken marketplace entry:

codex plugin marketplace remove openai-bundled
Restore/recreate this missing manifest:

%USERPROFILE%.codex\plugins\bundled-marketplaces\openai-bundled.agents\plugins\marketplace.json

The manifest needs local entries for:

./plugins/browser
./plugins/chrome
./plugins/computer-use
./plugins/latex

Re-add the marketplace:

codex plugin marketplace add "$env:USERPROFILE.codex\plugins\bundled-marketplaces\openai-bundled"
If you use Edge with the Codex Chrome extension, check the Edge native messaging host too. Chrome and Edge use separate registry keys. This was missing on mine:

$manifestPath = "$env:LOCALAPPDATA\OpenAI\extension\com.openai.codexextension.json"
$key = "HKCU:\Software\Microsoft\Edge\NativeMessagingHosts\com.openai.codexextension"
New-Item -Path $key -Force | Out-Null
Set-ItemProperty -Path $key -Name "(default)" -Value $manifestPath
Fully restart Codex and Edge/Chrome.

After this, codex plugin list showed:

browser@openai-bundled       installed, enabled
chrome@openai-bundled        installed, enabled
computer-use@openai-bundled  installed, enabled

and codex doctor --summary ended clean: 17 ok - 1 idle - 0 warn - 0 fail ok.

This probably does not fix every upstream bug, but it fixed the local plugin/cache/native-host state where Browser/Chrome/Computer Use disappeared or the extension was connected but unavailable to Codex.

Additional Windows data point: the Chrome plugin remains installed/enabled after restart, but Codex Desktop never creates the native-host manifests or exposes the Chrome control tool.

Environment

Windows 11 x64, build 10.0.26220
Codex Desktop 26.721.3996.0
Codex CLI 0.145.0-alpha.30
chrome@openai-bundled 26.721.31836
ChatGPT Chrome Extension 1.2.27221.15725_0
Google Chrome 150.0.7871.187

User-visible error

The Chrome side panel shows:

Codex Chrome native host v2 manifest is missing

Verified local state

Chrome is installed and running.
The ChatGPT Chrome Extension is installed and enabled in the selected Chrome profile.
chrome@openai-bundled is reported as installed, enabled.
The plugin cache is complete (376 files).
The latest junction correctly targets the installed 26.721.31836 cache directory.
scripts/browser-client.mjs and extension-host/windows/x64/extension-host.exe both exist.
The bundled marketplace was refreshed from the current Desktop package into an unencrypted user-local mirror to avoid WindowsApps os error 6000.

However, after uninstalling/reinstalling the Chrome plugin from the Codex UI and fully restarting Codex multiple times, all of these remain missing:

%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

Chrome tool discovery also does not expose the required browser execution tool (node_repl js returns no tool results), so Codex cannot list or control Chrome tabs.

Additional diagnostics

codex doctor --json reports the installation, config, authentication, provider reachability, and WebSocket handshake as OK. Overall status is only warning because the bundled rg.exe cannot be executed (os error 5), which appears unrelated.

Expected behavior

Installing the bundled Chrome plugin from the Codex UI should create the native-host registration/manifest, publish the v2 app-server manifest, and expose the Chrome control tool in a fresh/restarted Desktop session.

This appears to be a Desktop-side install-hook or plugin/tool-injection failure rather than a Chrome installation or extension-profile problem.

Additional restart-persistence reproduction on macOS 26.5.2 / Apple Silicon:

ChatGPT Desktop: 26.721.41059
Embedded CLI: codex-cli 0.146.0-alpha.3.1

A supported repair temporarily produced the expected state:

computer-use@openai-bundled installed and enabled
no standalone [mcp_servers.computer-use] override
Computer Use transport derived from the plugin manifest: ./bin/computer-use-client-launcher
CODEX_HOME present in the manifest-declared environment
Computer Use MCP enabled
the remote HyperFrames plugin was installed and its five task skills were exposed

After a full app restart, the repair did not persist:

ChatGPT launched at 2026-07-25 02:25:49 PDT; the embedded Codex process launched one second later.
The active config was recreated about nine seconds after launch.
A standalone [mcp_servers.computer-use] block reappeared with enabled = false.
Its transport reverted to ./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient, args ["mcp"], and no CODEX_HOME env declaration.
The bundled plugin itself still reported installed/enabled, so plugin registration and MCP activation/projection disagreed.
The Plugins page initially remained indefinitely on Loading.
In that first post-restart task, the remote HyperFrames cache/install marker still existed, but the five HyperFrames skills were not exposed and the active plugin association had reverted to the older local hyperframes@openai-curated projection.

After another restart, the Plugins page recovered and the current task again exposes the five remote HyperFrames 0.1.2 skills, but the Computer Use MCP is once again shown disabled. This makes the task/plugin hydration intermittent while the Computer Use activation failure remains reproducible across restarts.

No Computer Use/MCP capability was invoked during the acceptance check, and no config, plugin, or cache file was manually written during that check.

Network caveat: this machine requires a tunnel to reach Codex, so a direct-network A/B test is not available. Startup logs did show connection-refused events through the tunnel, which may contribute to the Plugins directory loading failure, but this does not by itself explain the app recreating the stale standalone Computer Use override. The Plugins page later recovered under the same required network path while the MCP still reverted to disabled.

Expected persistence invariant: after restart, installed/enabled plugin state, the manifest-derived MCP transport, MCP activation, and task-level skill/tool exposure should remain coherent; the app should not recreate an older standalone MCP override.

Follow-up on the HyperFrames side of the same restart/hydration problem:

The current task is loading the five HyperFrames skills from the remote cache (openai-curated-remote/hyperframes/0.1.2).
The active config nevertheless still enables hyperframes@openai-curated and declares the local openai-curated marketplace source under ~/.codex/.tmp/plugins.
The older local source and cache (openai-curated/hyperframes/11c74d6b) still exist.
Plugin Management resolves both hyperframes@openai-curated and hyperframes@openai-curated-remote to the same canonical plugin ID (Plugin_d72b815ecf6481919e3beede9c71ef08), currently installed/enabled.

This makes a supported targeted cleanup impossible: uninstalling the apparent old reference would uninstall the current canonical HyperFrames plugin too, while deleting only the old cache would leave the enabled local config/marketplace reference in place and allow it to be recreated on restart. No cache or plugin state was deleted during this check.

Additional Windows reproduction with a narrower root-cause signal from August 4, 2026.

Environment

Windows x64, OS build 26200
Codex desktop AppX: 26.727.6591.0
Bundled Chrome plugin: 26.727.51351
Google Chrome: 150.0.7871.187
ChatGPT Chrome extension: 1.2.27236.6274_0

Observed state

The browser extension itself is installed and enabled in Chrome's selected Default profile, and codex plugin list reports:

chrome@openai-bundled        installed, enabled  26.727.51351
computer-use@openai-bundled  installed, enabled  26.727.51351
browser@openai-bundled       installed, enabled  26.727.51351

The Chrome plugin cache is complete (380 files), including:

scripts/browser-client.mjs
extension-host/windows/x64/extension-host.exe

A stale latest junction was found pointing to 26.707.72221. It was backed up and corrected to 26.727.51351. The corrected junction persisted across a full Codex restart.

After uninstalling/reinstalling the Chrome plugin from the Codex UI and fully restarting Codex again, the native-host wiring was still absent:

%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

The bundled diagnostic reports:

exists: false
correct: false
problem: Windows native host registry key does not exist; Native host manifest does not exist

The runtime selection still fails with:

Browser is not available: chrome

New minimal reproduction: encrypted AppX file copy failure

The desktop log repeatedly records:

[BundledPluginsMarketplace] bundled_plugins_marketplace_resolve_failed
errorMessage="UNKNOWN: unknown error, copyfile
'C:\Program Files\WindowsApps\OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\sites\.app.json'
->
'%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-...\plugins\sites\.app.json'"

Inspecting that exact source file shows:

Attributes: Archive, Encrypted
Length: 105 bytes

A minimal copy of only this one file to a new local temporary directory fails independently of Codex:

The specified file could not be encrypted.
HRESULT: 0x80071770

This suggests that the Windows bundled-marketplace rebuild uses a copy operation that tries to preserve the AppX file's encrypted attribute and fails when materializing the user-local marketplace. The plugin list can still look healthy through an existing unencrypted local mirror, while the supported UI reinstall flow does not create the Chrome native-host manifest or registry key.

Expected

The Windows app should materialize bundled plugin files without attempting to preserve the protected AppX encryption attribute (for example, by reading and writing file contents into the user-local mirror), then complete the official Chrome native-host installation hook. If that copy fails, the Plugins/Computer Use UI should surface the actual error instead of reporting a successful reinstall.

No native-host manifest or registry key was created manually during this investigation.

Adding a fresh macOS reproduction with a slightly different native-host failure mode: the manifest exists and the bundled diagnostic reports it as correct, but the executable path declared by the manifest does not exist.

Environment:

macOS, Apple Silicon
ChatGPT Desktop 26.803.41515 (build 6321)
Codex CLI 0.147.0
Google Chrome 151.0.7922.108
ChatGPT Chrome extension 1.2.27236.6274_0, installed and enabled in the active Default profile
chrome@openai-bundled 26.803.41515, installed and enabled

Observed state:

Chrome is running.
The extension check reports installed=true and enabled=true.
The Chrome native messaging manifest exists.
check-native-host-manifest.js --browser chrome --json reports correct=true.
However, the manifest points to:
~/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/ChatGPT for Chrome
That target does not exist and there is no latest entry under the Chrome plugin cache.
The host binary does exist under the versioned 26.803.41515 directory.
agent.browsers.get("chrome") consistently returns: Browser is not available: chrome

Desktop logs classify the plugin as installed/current and skip reinstalling it:

chromeExtensionSyncAction=keep_installed
installedPluginStatus=current
bundled_plugin_install_skipped_current pluginName=chrome

During automatic reinstall, the logs report plugin_install_succeeded, but I could not find a corresponding native-host manifest install event. Native-host manifest removal events are logged when the plugin is uninstalled.

Recovery attempts already tried:

Disable/enable the Chrome plugin
Uninstall/reinstall the Chrome extension
Remove/re-add the Chrome plugin from the desktop UI
Restart Chrome
Restart ChatGPT Desktop
Start a fresh chat
Retry the browser connection after a two-second delay

None restored the missing latest target.

This appears to be a reconciliation/validation bug:

The app considers the plugin current even though the manifest's executable target is missing.
check-native-host-manifest.js validates the host name and origins but does not appear to validate that the declared executable exists and is executable.
The native host path relies on a mutable latest cache entry that is absent after reconciliation.

Suggested checks/fix:

Validate manifest.path existence and executability before reporting correct=true.
Treat a missing latest target as an invalid plugin installation and repair it through the supported plugin lifecycle.
Prefer a stable native-host location outside the mutable plugin cache, or atomically maintain the latest target across reconciliation.

I can reproduce this issue on a newer macOS/ChatGPT build.

Environment:

macOS 27.0 (26A428), arm64
ChatGPT.app 26.915.31945, build 9922
Chrome 153.0.8010.53
ChatGPT Chrome extension 1.26.901.11451
Codex CLI 0.155.1

Current state:

browser@openai-bundled: installed/enabled
computer-use@openai-bundled: installed/enabled
chrome@openai-bundled: present in ChatGPT.app but NOT installed
bundled extension-host is present
Native Messaging manifest is missing:
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json
official checker reports:
exists: false
correct: false

The ChatGPT UI shows Google Chrome as:
“Browser extension not installed”

The extension itself shows:
“Install the app to use ChatGPT in Chrome”

Reinstalling the ChatGPT app and Chrome extension did not resolve it.

I did not manually create the manifest or run installManifest.mjs.

Feedback ID:
no-active-thread-01a0c745-a9b0-70a2-8927-2994f9694fbb

Navigation Menu

Repository navigation

Codex Desktop plugins disappear after restart; Chrome native host manifest is not created and computer-use MCP is not attached #25809

Summary

Environment

Expected behavior

Actual behavior

Checks already performed

Important constraint

Reproduction pattern

Related issues

Additional debug export

Environment

User-visible error

Verified local state

Additional diagnostics

Expected behavior

Environment

Observed state

New minimal reproduction: encrypted AppX file copy failure

Expected

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex Desktop plugins disappear after restart; Chrome native host manifest is not created and computer-use MCP is not attached #25809

Description

Summary

Environment

Expected behavior

Actual behavior

Checks already performed

Important constraint

Reproduction pattern

Related issues

Additional debug export

Activity

github-actions commented on Jun 2, 2026

jason-chang commented on Jun 3, 2026

cocogoat-a commented on Jun 3, 2026

MaxxxDong commented on Jun 4, 2026

instaer commented on Jun 4, 2026

stevenworld75 commented on Jun 7, 2026

Demon-Lee commented on Jul 24, 2026

Environment

User-visible error

Verified local state

Additional diagnostics

Expected behavior

zengzheqing commented on Jul 25, 2026

zengzheqing commented on Jul 25, 2026

wwwu379-dot commented on Aug 4, 2026

Environment

Observed state

New minimal reproduction: encrypted AppX file copy failure

Expected

luke-timon commented on Aug 9, 2026

jhdevmx commented on Sep 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions