Codex App overwrites bundled plugin config/cache and removes Computer Use/Browser plugins

Resolved 💬 5 comments Opened Jun 2, 2026 by nguyentrungtu Closed Jun 18, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.527.60818 Bundle version: 3437 Bundle identifier: com.openai.codex

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex App is repeatedly removing the bundled Computer Use, Browser, and Chrome plugins from the active config/cache.

Computer Use disappeared from the available tools. I inspected ~/.codex/config.toml and found that computer-use@openai-bundled had previously appeared under disabled tools, and later the plugin enable stanzas were missing entirely.

The bundled plugins do exist inside the app bundle:

  • /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/browser
  • /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/chrome
  • /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use
  • /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/latex

The app bundle marketplace JSON lists all four plugins: browser, chrome, computer-use, and latex.

However, the active generated marketplace/cache is being rewritten to LaTeX-only:

  • ~/.codex/.tmp/bundled-marketplaces/openai-bundled/.agents/plugins/marketplace.json lists only latex
  • ~/.codex/plugins/cache/openai-bundled contains only latex
  • ~/.codex/config.toml loses these stanzas:
[plugins."browser@openai-bundled"]
enabled = true

[plugins."chrome@openai-bundled"]
enabled = true

[plugins."computer-use@openai-bundled"]
enabled = true

I manually restored the marketplace/cache/config from the bundled app plugin source, and the state was correct briefly. Then the running Codex App modified the files again at the same timestamp and reverted them back to LaTeX-only.

Observed timestamp of overwrite:
2026-06-02 10:02:15 +0700 ~/.codex/config.toml
2026-06-02 10:02:15 +0700 ~/.codex/plugins/cache/openai-bundled
2026-06-02 10:02:15 +0700 ~/.codex/.tmp/bundled-marketplaces/openai-bundled

This appears to be an app-side overwrite/sync policy issue, and not a missing plugin file issue.

What steps can reproduce the bug?

  1. Start with Codex App installed at /Applications/Codex.app.
  1. Confirm bundled plugins exist in the app bundle:
find /Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins -maxdepth 1 -type d -print

Expected entries include:
browser
chrome
computer-use
latex

  1. Confirm active generated bundled marketplace/cache only contains LaTeX:
find ~/.codex/.tmp/bundled-marketplaces/openai-bundled -maxdepth 5 \( -name marketplace.json -o -name plugin.json -o -name SKILL.md -o -name .mcp.json \) -print | sort

find ~/.codex/plugins/cache/openai-bundled -maxdepth 5 \( -name plugin.json -o -name SKILL.md -o -name .mcp.json \) -print | sort
  1. Manually restore the bundled plugin source to a stable local marketplace and cache.
  1. Add the following to ~/.codex/config.toml:
[plugins."browser@openai-bundled"]
enabled = true

[plugins."chrome@openai-bundled"]
enabled = true

[plugins."computer-use@openai-bundled"]
enabled = true
  1. Verify the config/cache contains Computer Use.
  2. Continue using/restart Codex App.
  3. Observe that Codex App rewrites:
~/.codex/config.toml
~/.codex/plugins/cache/openai-bundled
~/.codex/.tmp/bundled-marketplaces/openai-bundled

back to a LaTeX-only bundled plugin state.

What is the expected behavior?

Codex App should preserve and load the bundled browser, chrome, and computer-use plugins when they are present in the app bundle and enabled in ~/.codex/config.toml.

The generated bundled marketplace/cache should not be rewritten to LaTeX-only when the app bundle marketplace contains all four bundled plugins.

Computer Use and Browser tools should appear in the live tool registry after restart.

Additional information

The app bundle itself appears valid:

CFBundleDisplayName: Codex
CFBundleIdentifier: com.openai.codex
CFBundleShortVersionString: 26.527.60818
CFBundleVersion: 3437

The source marketplace copy remains intact and contains all bundled plugins, while the active generated marketplace/cache is repeatedly rewritten to LaTeX-only. This suggests the problem is in Codex App plugin sync/registration logic rather than file absence.

The issue started after I asked ChatGPT/Codex to add a new skill. Computer Use had been available before that.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25253

Powered by Codex Action

nguyentrungtu · 2 months ago

Yeah that is the same issue. Appears to be on both MacOS and Windows then.

jason-chang · 2 months ago

Adding another data point from a macOS 26.5 machine. This may be adjacent to the bundled plugin availability/cache issue here, but the local evidence points to a related Computer Use failure mode: 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:

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

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

OhHeyAlan · 2 months ago

Hope this can be fixed soon. Both my macs are affected.

nguyentrungtu · 2 months ago

The issue is fixed on my Mac.