ChatGPT Desktop startup rewrites bundled computer-use MCP to enabled=false while plugin stays enabled #34807

Summary

Launching ChatGPT Desktop on macOS rewrites the shared ~/.codex/config.toml entry for the bundled computer-use MCP server to enabled = false, while leaving computer-use@openai-bundled itself enabled. The next CLI read confirms that the MCP is disabled.

This is a persistence/reconciliation defect, not a missing or unsigned helper. The official Computer Use setup documentation exposes two separate controls and instructs users to turn on both the Computer Use server and skill toggles. It does not document a launch-time reset of either control.

Reproduction

1. Install and enable the bundled Computer Use plugin.

2. Enable its MCP server and verify both persisted states:

   [plugins."computer-use@openai-bundled"]
   enabled = true
   
   [mcp_servers.computer-use]
   command = "<absolute path to signed bundled helper>"
   args = ["mcp"]
   cwd = "<absolute plugin directory>"
   enabled = true

3. Fully launch ChatGPT Desktop.

4. Read only the two relevant sections of ~/.codex/config.toml, then run codex mcp get computer-use.

Expected behavior

ChatGPT Desktop should preserve the user's enabled MCP state while reconciling the first-party bundled plugin. If path normalization is required, it should not change the enablement decision.

Actual behavior

The plugin remains enabled:

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

But the MCP entry is rewritten to:

[mcp_servers.computer-use]
command = "./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient"
args = ["mcp"]
cwd = "."
enabled = false

codex mcp get computer-use then reports:

computer-use (disabled)

Timestamped before/after evidence

All timestamps below are from the same Mac in Europe/Lisbon time on July 22, 2026:

This establishes a launch-correlated write to the shared config. It does not identify which internal ChatGPT reconciliation component performed the write.

Bundled manifest and signature evidence

The first-party plugin manifest supplies command resolution but no enablement policy:

{"mcpServers":{"computer-use":{"command":"./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient","args":["mcp"],"cwd":"."}}}

Byte-identical copies of this manifest are present in the ChatGPT app bundle, the user plugin cache, and the generated bundled-marketplace snapshot. None contains an enabled field.

The corresponding helper app in each of those three locations passes strict/deep code-signature verification with:

Identifier=com.openai.sky.CUAService
Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
TeamIdentifier=2DC432GLL2

There is therefore no evidence here of a corrupt, modified, or unsigned Computer Use bundle.

Environment

• macOS 26.5.2 (25F84), Apple Silicon (arm64)
• ChatGPT Desktop 26.715.72359, bundle build 5718
• Embedded CLI: codex-cli 0.145.0-alpha.30
• PATH CLI: codex-cli 0.145.0
• Computer Use helper 26.715.1000451, build 1000451

Non-duplication and scope boundary

• Codex Desktop plugins disappear after restart; Chrome native host manifest is not created and computer-use MCP is not attached #25809 and Computer Use plugin becomes unavailable after Codex Desktop restart #26429 concern restart instability, missing/uninstalled plugins, marketplace races, stale paths, or tools not attaching. This reproduction retains the plugin and isolates a persisted enabled = true to enabled = false MCP rewrite during ChatGPT launch.
• Plugin MCPs are disabled when plugin requirements contain no MCP allowlist #34110 concerns effective runtime disabling from plugin requirement filtering, not a physical launch-time rewrite of the user's MCP stanza.
• A separate stale app-server from an older runtime was present with PPID 1 and an old control socket. It started the previous day. It is a cleanup concern, but no evidence attributes the 19:16:58 config write to it, so it is not presented as the cause.

Requested fix

Please make first-party plugin/MCP reconciliation preserve the user's persisted Computer Use server enablement, or establish one authoritative persisted setting that keeps the plugin and MCP controls synchronized. Rewriting command/cwd fields must not silently reset enabled to false.

The supported fix should live in the first-party reconciliation path. Users should not need to patch signed app/plugin bundles, run a config watchdog, or maintain a persistent override merely to retain the documented enabled state across launch.