Disabled `computer-use` MCP config uses invalid relative path and breaks third-party MCP discovery

Trace the code that writes ~/.codex/config.toml and the plugin-cache .mcp.json files for the computer-use server. Reproduce discovery with the server disabled, then determine how disabled entries and relative commands are exported; done means third-party scanners no longer attempt to launch the disabled server and valid enabled configurations still work.

Summary

Codex Desktop leaves disabled, plugin-managed computer-use MCP server configuration in globally discoverable MCP config locations. Third-party tools that scan known agent config files can pick up this disabled server and attempt to spawn it anyway.

In my case, Warp's "Auto-spawn servers from third-party agents" feature detected Codex's computer-use MCP server configuration and attempted to start it, even though Codex had the server set to disabled. The spawn failed because the exported command is a relative path with cwd = ".", which is not resolvable from the third-party tool's working directory.

This produced persistent MCP connection errors in Warp that could not be removed through Warp's UI, because Warp was re-discovering the server from Codex-managed config files.

Environment

• OS: macOS Tahoe 26.5.2
• Hardware: Apple Silicon MacBook Pro
• App: ChatGPT/Codex Desktop v26.715.72359
• Plugin: OpenAI-bundled Computer Use plugin
• Third-party tool affected: Warp v0.2026.07.22.09.01.stable_01

Codex Config Observed

Codex showed Computer Use installed, but the MCP server toggle was off/disabled. However, ~/.codex/config.toml still contained:

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

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

The enabled = false field appears to be Codex-specific metadata. Third-party MCP config readers do not necessarily know to honor it.

Plugin Cache Configs Observed

The plugin cache also exposed .mcp.json files containing a computer-use MCP entry without any enabled/disabled state:

~/.codex/plugins/cache/openai-bundled/computer-use/1.0.1000451/.mcp.json
~/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/computer-use/.mcp.json

Those files contained this kind of entry:

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

Because these are standard-looking MCP configuration files with no disabled flag, third-party tools can reasonably treat the server as available.

Actual Installed Paths

The real executable exists under the Codex home directory:

~/.codex/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient

A plugin launcher also exists in the plugin cache:

~/.codex/plugins/cache/openai-bundled/computer-use/1.0.1000502/bin/computer-use-client-launcher

That launcher resolves the real client through CODEX_HOME:

${CODEX_HOME:-${HOME}/.codex}/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient

There also appears to be a newer plugin .mcp.json shape that points at the launcher instead:

{
  "mcpServers": {
    "computer-use": {
      "command": "./bin/computer-use-client-launcher",
      "args": ["mcp"],
      "cwd": ".",
      "env_vars": ["CODEX_HOME"]
    }
  }
}

That is better than pointing directly at ./Codex Computer Use.app/..., but it may still be ambiguous for third-party readers unless cwd is resolved relative to the plugin directory.

Error Seen in Warp

Warp attempted to auto-spawn the disabled server and produced errors like:

[error] MCP: Failed to spawn 'computer-use': command './Codex Computer Use.app/.../SkyComputerUseClient' not found (cwd: .)
[error] MCP: Failed to connect to server: Transport creation error: No such file or directory (os error 2)

Expected Behavior

Disabled plugin-managed MCP servers should not be exposed in a way that third-party MCP discovery tools interpret as globally available.

At least one of these should be true:

1. Disabled plugin-managed MCP server entries are removed from ~/.codex/config.toml.
2. Disabled plugin-managed MCP server entries are not written to standard .mcp.json files in discoverable plugin/cache locations.
3. If disabled entries must remain, their disabled state is represented in a way that third-party-compatible tooling can reliably detect or ignore.
4. Exported MCP commands use resolvable absolute paths, a stable launcher command, or a clearly valid working directory.

Actual Behavior

Codex leaves a disabled computer-use MCP entry in ~/.codex/config.toml:

./Codex Computer Use.app/... with cwd = "."

Codex also exposes plugin cache .mcp.json files that contain the same server without an enabled/disabled field.

Third-party tools that scan known MCP config locations can therefore discover and try to spawn computer-use, even though the user disabled the server in Codex. Since the command is relative and cwd = ".", the command is invalid outside Codex's expected execution context.

Local Verification

Verified locally:

• The Codex UI showed the computer-use MCP server disabled.
• ~/.codex/config.toml still contained [mcp_servers.computer-use] with enabled = false.
• Plugin cache .mcp.json files contained computer-use entries with no disabled field.
• The invalid relative command did not exist from the current third-party/workspace context.
• The real executable existed under ~/.codex/computer-use.
• Warp repeatedly rediscovered the server and reported MCP spawn/connect errors.
• Removing the [mcp_servers.computer-use] block from ~/.codex/config.toml and deleting the plugin cache .mcp.json entries stopped Warp from discovering the broken server.

Not verified:

• ChatGPT suggested that using working_directory = "~/.codex/computer-use" should make the direct relative command resolvable, because that is where Codex Computer Use.app exists. This has not been tested or confirmed.

Why This Looks Like a Codex Bug

• Codex writes or retains disabled plugin-managed MCP configuration in locations third-party tools scan.
• enabled = false in TOML appears to be Codex-specific and is not a reliable interoperability signal.
• The plugin cache .mcp.json files are standard MCP-style configs and contain no disabled state.
• The relative command plus cwd = "." is fragile outside Codex's internal launch context.
• A disabled server should not create user-visible errors in other MCP-aware tools.

Configuration Hygiene Concern

Separate from the third-party interoperability failure, this also looks like a configuration hygiene issue. A disabled plugin-managed MCP server remains represented as an apparently launchable server in user-visible/global config files and plugin cache .mcp.json files.

That makes the user's local Codex state harder to reason about: the UI says the server is disabled, while persisted config still describes a server that external tools can discover and attempt to run. Keeping disabled or stale plugin-managed MCP entries out of globally discoverable config would make Codex's persisted state better match the UI state and reduce accidental side effects across MCP-aware tooling.

Suggested Fixes

Possible fixes:

1. Do not write disabled plugin-managed MCP server entries to ~/.codex/config.toml.
2. Do not expose disabled plugin MCP configs in standard .mcp.json files in globally discoverable cache/temp locations.
3. If Codex needs to retain disabled entries, store them in a Codex-private config file not intended for third-party MCP discovery.
4. Include a clear namespaced disabled marker such as "x-codex-enabled": false in plugin .mcp.json files, so third-party tools can choose to honor it.
5. Prefer the plugin launcher over the direct app-relative path.
6. Ensure exported MCP server definitions have a resolvable command and working directory when read outside Codex.
7. Consider publishing an explicit registry/sentinel file for MCP servers intended to be globally available, instead of requiring third-party tools to infer availability from all plugin cache configs.

Related Issues

• #20851: First-class Computer Use support from Codex CLI. Shows the same MCP command shape with ./Codex Computer Use.app/... and cwd = ".".
• #25809: Codex Desktop plugins disappear after restart; mentions computer-use can appear enabled in MCP state but not attached, and stale paths reappearing.
• #21200: SkyComputerUseClient SIGKILL outside Codex.app; notes disabling Computer Use in UI/config may not fully prevent helper behavior in third-party adapter contexts.
• #21579: Computer Use does not appear in Settings despite plugin/helper existing; general UI/config mismatch.
• #18307: Not the same bug, but shows MCP/tool config leaking into third-party integrations and breaking them.