Computer Use does not appear in Settings despite plugin and helper existing
Resolved 💬 7 comments Opened May 7, 2026 by ShalevZorany Closed Jun 16, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Short description
Computer Use does not appear in Codex Settings, and the assistant cannot use Computer Use actions, even though the bundled plugin and helper app appear to be installed and enabled.
What we already tried
- Tried to use Computer Use directly (e.g., request to open Calculator without terminal commands).
- Verified local Codex configuration and plugin enablement.
- Verified local plugin/helper installation paths.
- Checked whether the related service process is running.
Diagnostic results
Environment:
- macOS: 26.5 (Build 25F71)
- CPU: arm64, Apple A18 Pro
- Codex CLI: codex-cli 0.129.0-alpha.15
Checks:
features.apps = trueis present in~/.codex/config.toml.[plugins."computer-use@openai-bundled"]exists withenabled = truein~/.codex/config.toml.- Bundled plugin path exists:
/Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use- Plugin cache entry exists:
/Users/shalevzorany/.codex/plugins/cache/openai-bundled/computer-use- Helper app exists:
/Users/shalevzorany/.codex/computer-use/Codex Computer Use.app/Users/<user>/Applications/Codex Computer Use.appSkyComputerUseServicewas not running at initial check; it appeared after manual helper launch.
Expected behavior
Computer Use should appear in Settings and be available to the assistant once plugin + helper are installed and enabled.
Actual behavior
Computer Use does not appear in Settings, and Computer Use actions are unavailable in-session.
Request to OpenAI team
Could you please check whether this is:
- an account-level availability/rollout issue, or
- a bug in plugin discovery/loading (or helper/service startup)?
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
A couple of angles worth checking on a setup that visually looks complete but still won't surface Computer Use in Settings:
1. The dual helper-app install is the most common culprit when every other check passes. You have the helper at both:
~/.codex/computer-use/Codex Computer Use.app~/Applications/Codex Computer Use.appThe Settings UI discovers helpers via LaunchServices, while the runtime discovers them via the
~/.codex/plugins/cache/.../mcp.jsonentry. If both helper copies share a bundle ID but have different codesign Team IDs (or one is a stale leftover from a prior install),lsregisterends up pinning the "wrong" copy and the UI just hides the row instead of erroring. Worth running:If the two
TeamIdentifiers differ, orlsregistershows two registrations, that's the gap — remove the older copy and runlsregister -kill -r -domain local -domain userbefore relaunching Codex.2.
codex-cli 0.129.0-alpha.15is a prerelease. Alpha builds can introduce a flag/schema shift on the discovery path that backs the Settings UI while leaving the runtime'scodex mcp listpath unchanged — that's exactly the pattern that produces "everything looks installed but Settings is empty." Quickest control test: install the closest stable CLI without touching your config or cache, launch once, and check if Settings populates. If it does, the gap is in alpha-15's Settings discovery rather than anything you set up wrong; if it doesn't, skip this and focus on #1.3. The Settings tab is process-cached. Even on a fully correct setup, a Settings tab opened during a previous launch won't repopulate without a full
Codex.appquit/relaunch and acodex mcp listfrom the same user shell that owns the plugin cache. Worth a clean cycle before going deeper.---
I run a Mac AI-agent setup service and just published a longer walkthrough covering six classes of "Computer Use looks installed but isn't" failures (the dual-helper / LaunchServices pinning case above is adjacent to class 1): https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html. If the
lsregister+codesignoutput don't reveal the gap, sending the redacted log via the $19 quick read on that page is the cheapest async path to a specific answer.Thanks for the detailed suggestions. I worked through each of the items you outlined.
Current state:
~/Applications/Codex Computer Use.appentirely.~/.codex/computer-use/Codex Computer Use.app(version 780)/Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.app(version 770)com.openai.sky.CUAService) and the same TeamIdentifier.lsregister -r -domain local -domain userand thenlsregister -f ~/.codex/computer-use/Codex Computer Use.app..mcp.jsonin the plugin points toSkyComputerUseClientand that codesign verification passes.Result:
codex mcp liststill only showsxcodebuildmcp, and the Computer Use row still does not appear in Settings.Based on these results, it doesn't look like a stale LaunchServices registration or alpha CLI issue anymore. Could this be a rollout/availability gating or perhaps a discovery bug in Codex.app itself?
Thanks again for your help.
Thorough writeup — that rules out the LaunchServices/codesign theory and the alpha-CLI schema theory cleanly. Three more angles worth checking before treating it as a server-side gate:
1. Re-hydrate the cache against the stable CLI specifically. The v780 cache entry under
~/.codex/computer-use/was hydrated by the 0.129.0-alpha.15 CLI. The 0.130.0 stable CLI may keep that cache file but refuse to register it because the cache format / version stamp embedded inside.codex-plugin/plugin.jsonwas emitted by an alpha schema. Worth forcing a clean re-hydration:If the cache file's
version/schemaVersionfield doesn't match what 0.130.0 expects, a re-hydration is the only path that fixes it —lsregisterand codesign won't surface the mismatch.2. Account-level entitlement. Codex Computer Use is gated by ChatGPT account tier on some accounts, independent of the local install. The Settings UI hides the row when the account entitlement check fails, even though the bundle is locally complete. Worth confirming with:
If your account doesn't have
computer_usein entitlements, no amount of local fixing will surface it.3. The
xcodebuildmcp-only listing is a clue.codex mcp listreturning just one entry (not even an error for computer-use) usually means the marketplace registry was reset (cache eviction during upgrade) but the new CLI didn't auto-re-add the bundled marketplace. Confirmed by runningcodex plugin marketplace list— ifopenai-bundledis absent from that list entirely, the manual re-add in step 1 is the fix.If all three rule out: yes, it's almost certainly a rollout/availability gate, and the only path is contacting OpenAI support with your account ID + the auth.json entitlement output.
If you'd rather get the bundle reviewed in one shot — including the
auth.jsonentitlement check and a confirmed "rollout gate vs local config" verdict — the $19 quick read does same-day root-cause notes against your full bundle: https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/speed-to-lead.html(Free walkthrough of the six root-cause classes is still at https://igorganapolsky.github.io/openclaw-mac-ai-workstation-setup/troubleshooting.html — and there's a one-line
curl ... | nodeself-diagnose script there now that captures all surfaces into a redacted bundle.)Thanks @IgorGanapolsky — I went through the extra checks and found a more specific failure mode.
What I checked
LaunchServices / codesign
All visible helper copies have the same bundle identifier and TeamIdentifier:
This was true for:
The cached helper also verifies correctly:
Cache / plugin metadata
The cache is now hydrated under:
The cached
plugin.jsonmatches the app bundle plugin metadata:codex mcp listnow does see the MCP server:So this no longer looks like a missing cache entry or a broken
.mcp.json.Chrome side
The Chrome extension is installed/enabled and the native messaging manifest is correct after repair:
The actual failure I found
The strongest evidence is in the Codex Desktop logs. On every app startup, Codex rewrites the runtime bundled marketplace with only
browserandlatex, then explicitly uninstalls/removeschromeandcomputer-usebecause they are not in that generated list:This repeats after a full
Command+Q/ relaunch.That seems to explain the confusing state:
chromeandcomputer-usecodex debug prompt-input/ runtime can see the skills after repairopenai-bundledasbrowser+latexonly, then removes the two plugins and the Chrome native host manifestCurrent workaround tested locally
A local repair script can restore the full bundled marketplace from:
and re-register the Chrome native host after Codex removes it. With that in place, runtime/debug sees both:
However, this is only a workaround. The underlying issue appears to be that Codex Desktop’s
BundledPluginsMarketplacegeneration path is producing a reduced bundled marketplace (browser,latex) even though the installed app bundle contains the full marketplace (browser,chrome,computer-use,latex).At this point this looks less like LaunchServices/codesign/cache corruption and more like either:
One more small note: in this build,
codex plugin marketplaceonly exposesadd,upgrade, andremove; there is nolistsubcommand available, so I could not use that exact suggested check.Update from the same Mac mini: the visible symptom has changed.
Computer Use now appears in Codex Settings, but the shown controls are disabled with this exact message:
This is a personal ChatGPT Plus account, and the user is located in Israel.
Verified diagnostics from this Mac mini:
en_IL; timezoneAsia/Jerusalem.codex-cli: codex-cli 0.133.0-alpha.1.No; MDM enrollmentNo./Applications/Codex.app/Contents/Resources/plugins/openai-bundled/plugins/computer-use/Codex Computer Use.apppresent, bundlecom.openai.sky.CUAService, TeamIdentifier2DC432GLL2, codesignpassed;~/.codex/plugins/cache/openai-bundled/computer-use/1.0.793/Codex Computer Use.apppresent, bundlecom.openai.sky.CUAService, TeamIdentifier2DC432GLL2, codesignpassed;~/Applications/Codex Computer Use.apppresent, bundlecom.openai.sky.CUAService, TeamIdentifier2DC432GLL2, codesignpassed. All discovered helper copies match:yes.~/.codex/config.toml: existsyes;[features]sectionyes; explicitcomputer_usesettingnot present;computer-use@openai-bundledentryyes; browser entryyes; Chrome entryyes;openai-bundledmentionyes./Applications/Codex.app/Contents/Resources/plugins/openai-bundled/.agents/plugins/marketplace.jsonplugin names['browser', 'chrome', 'computer-use', 'latex'];~/.codex/.tmp/bundled-marketplaces/openai-bundled/.agents/plugins/marketplace.jsonplugin names['browser', 'chrome', 'computer-use', 'latex'].openai-bundledsourceyes; runtime log plugin names omitcomputer-useyes; reconciliation requests uninstall/exclusion ofcomputer-useyes.Relevant sanitized log excerpts:
Could you confirm whether Computer Use is currently unavailable for personal Plus accounts in Israel, or whether this points to an incorrect entitlement, organization policy, regional availability gate, feature gate, or bundled marketplace reconciliation state?
A screenshot showing the disabled controls is available if maintainers need it.
This appears to be resolved for me now after updating Codex.
My best guess is that it may have been related to the Computer Use / plugin availability rollout in Europe, which now seems to be available. That said, I am actually based in Israel, so the regional gating was a bit confusing from my side.
Closing this since the feature is now visible and working for me.