›_ Codex Issues
Codex Issues / #28247

chrome@openai-bundled plugin reinstall fails with "os error 5" (Access Denied) — stuck in repeated backup loop

Open 💬 2 comments Opened Jun 15, 2026 by macaroniyang-sketch
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

Codex CLI 0.139.0

What subscription do you have?

Chat GPT plus

Which model were you using?

gpt-5.5

What platform is your computer?

Platform: Windows Codex path: %LOCALAPPDATA%\OpenAI\Codex\bin\<version>\codex.exe Plugin version (inferred from cache directory): chrome@openai-bundled 26.609.41114 (previously 26.609.30741)

What terminal emulator and version are you using (if applicable)?

Windows Terminal (WSL / PowerShell)

Codex doctor report

What issue are you seeing?

Description:
I tried to remove and reinstall the chrome@openai-bundled plugin via the CLI to fix a "privileged native pipe bridge is not available" connection issue, but both plugin remove and plugin add fail with os error 5 (Access Denied). This persists even after a full system restart (Chrome and Codex fully closed before running the commands). I've attempted this same reinstall flow multiple times over the past three days, and every attempt fails the same way, leaving multiple uncleaned plugin-backup-* directories under .codex\plugins\cache\openai-bundled\ (currently 4: plugin-backup-5V3Ben, plugin-backup-mfPUDE, plugin-backup-OltIbN, plugin-backup-pA87dy).

What steps can reproduce the bug?

Steps to reproduce:
powershell$codex = Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin\*\codex.exe" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1 -ExpandProperty FullName

& $codex plugin remove chrome@openai-bundled --json
& $codex plugin add chrome@openai-bundled --json
Actual error (first attempt):
Error: failed to remove existing plugin cache entry: Access is denied. (os error 5)
Caused by:
0: failed to remove existing plugin cache entry: Access is denied. (os error 5)
1: Access is denied. (os error 5)
Actual error (subsequent retries):
Error: failed to back up plugin cache entry: Access is denied. (os error 5)
Caused by:
0: failed to back up plugin cache entry: Access is denied. (os error 5)
1: Access is denied. (os error 5)

What is the expected behavior?

Expected behavior:
plugin remove / plugin add should complete successfully and re-establish the Chrome extension's native messaging bridge, without repeatedly creating uncleanable backup folders under .codex\plugins\cache\openai-bundled\.
Additional context:
This appears related to #21862 and #22598 (plugin marketplace cache directory mismatch / Chrome plugin failing to reinstall properly). The issue persists across full system restarts with Chrome and Codex completely closed, suggesting a file permission/ownership issue with the cache directory rather than a process lock.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28084
  • #27234
  • #26785
  • #26692
  • #26792

Powered by Codex Action

zemeng5208 · 16 days ago

I maintain WinBridge Recovery for Windows Codex Desktop plugin-cache recovery: https://github.com/zemeng5208/winbridge-recovery

This is a strong match for the cache/file-lock layer the project handles. Repeated failed to remove existing plugin cache entry / failed to back up plugin cache entry with os error 5, plus accumulating plugin-backup-* directories, means the cache is not converging cleanly even though the user is following the normal remove/add path.

WinBridge v3.1.1 validates the current bundled source and versioned plugin cache, checks for known Codex/Chrome helper processes before replacement, builds verified staging copies first, and uses atomic swaps/rollback instead of repeatedly mutating the same cache tree in place. It also verifies latest and the Chrome Native Host state after repair.

One important distinction: os error 5 can be either a live handle/file-lock problem or a genuine ACL/ownership problem. The tool should not assume one from the error code alone; if the files remain inaccessible after relevant Codex/Chrome-owned helpers are gone, that should be surfaced as an unresolved permission condition rather than blindly taking ownership or changing WindowsApps/cache ACLs.

WinBridge never takes ownership of or patches WindowsApps, and it cannot fix the separate trusted native-pipe/tool-injection layer if the Chrome cache/native-host state is already healthy.