[macOS] Two profiles run duplicate Computer Use services at high CPU; disabling one does not tear it down

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

Codex App 26.727.40816 (CFBundleVersion 6067).

Bundled Computer Use service: 26.727.1000550 (CFBundleVersion 1000550, bundle identifier com.openai.sky.CUAService).

What subscription do you have?

Unknown — the subscription tier is not exposed in the local diagnostic data available for this report. The failure is in local process/configuration lifecycle behavior.

What platform is your computer?

Darwin 25.5.0 arm64 arm
macOS 26.5.1 (25F80)
Apple Silicon Mac17,3
16 GB RAM, 10 logical/physical CPU cores

What issue are you seeing?

Running two Codex/ChatGPT desktop instances with distinct Codex home/profile directories can start two independent copies of the macOS Computer Use service. Both copies have the same bundle identifier (com.openai.sky.CUAService) but are loaded from different filesystem paths.

In the observed failure, both Computer Use services consumed sustained high CPU at the same time. Disabling the Computer Use plugin in one instance through the UI correctly changed that profile's configuration to:

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

[mcp_servers.computer-use]
enabled = false

However, disabling it did not stop that profile's already-running SkyComputerUseService or its SkyComputerUseClient processes. It also left this installer-owned hook active in the disabled profile:

notify = ["<default-profile>/computer-use/.../SkyComputerUseClient", "turn-ended"]

Therefore every later turn could still invoke Computer Use code even though both the plugin and MCP server were disabled in that profile.

Process/CPU evidence

Activity Monitor showed the following in the same sample:

Computer Use service, default profile       ~74.6% CPU
Computer Use service, isolated profile      ~73.3% CPU
ChatGPT/Codex app                            ~73.2% CPU
launchservicesd                              ~44.6% CPU
System CPU idle                              ~10.1%

The two Computer Use services alone accounted for about 148% macOS process CPU (roughly 1.48 cores). Process inspection resolved them to two different service bundle paths:

<default-profile>/computer-use/Codex Computer Use.app/.../SkyComputerUseService
<isolated-profile>/computer-use/Codex Computer Use.app/.../SkyComputerUseService

After the UI disable operation, the disabled/default profile still had:

• one SkyComputerUseService process;
• four SkyComputerUseClient processes;
• the SkyComputerUseClient turn-ended notify hook shown above.

The enabled isolated profile had its own service and MCP client at the same time.

Recovery evidence

The high Computer Use/LaunchServices load stopped only after all three lifecycle remnants of the disabled profile were cleaned up together:

1. terminate its stale service and four client processes;
2. remove its stale turn-ended hook;
3. move its installed Computer Use runtime directory out of the active profile path (kept as a recoverable backup).

After that cleanup, without stopping the second/isolated instance:

Remaining isolated SkyComputerUseService     0.0% CPU
Remaining isolated SkyComputerUseClient      ~0.6–0.9% CPU
launchservicesd                              approximately 0% CPU
System CPU idle                              repeatedly ~54–73%

The disabled profile's runtime directory was not recreated and its notify hook was not restored during the observation window.

There was also an unrelated, long-running macOS Storage Settings scan on this machine. It was diagnosed and handled separately. The CPU values and before/after process checks above specifically concern the two SkyComputerUseService trees and launchservicesd; this report does not attribute the storage scan to Codex.

What steps can reproduce the bug?

1. On macOS, install and enable the bundled Computer Use plugin in a normal Codex desktop profile (the default Codex home).
2. Start a second Codex/ChatGPT desktop instance backed by a different Codex home/profile directory. Install and enable Computer Use there as well.
3. Confirm that each profile contains a separate Codex Computer Use.app bundle and that both copies report the same bundle identifier:

``bash
/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' \
'<profile>/computer-use/Codex Computer Use.app/Contents/Info.plist'
# com.openai.sky.CUAService
``

1. Use/open Computer Use in both instances, then observe both process trees:

``bash
pgrep -afil 'SkyComputerUseService|SkyComputerUseClient'
ps -Ao pid,ppid,%cpu,etime,command -r | \
grep -E 'SkyComputerUse(Service|Client)'
``

1. In the first/default instance, disable Plugins > Computer Use. Confirm that its plugin and MCP entries now say enabled = false.
2. Observe that its existing service/client processes remain alive and that its global/profile notify entry still points to SkyComputerUseClient turn-ended.
3. Continue using Codex or complete turns. The disabled profile can still invoke the stale Computer Use hook, and CPU does not reliably return to idle.
4. Terminate only the disabled profile's service/client tree and remove its stale hook. In this reproduction, the other profile's Computer Use service immediately returned to effectively idle CPU without being stopped.

This reproduction uses normalized profile paths because the exact paths contain machine-specific identifiers.

What is the expected behavior?

• Disabling Computer Use in a profile should synchronously stop, or promptly and reliably drain, every Computer Use service/MCP client owned by that profile.
• The disable operation should remove its installer-owned SkyComputerUseClient turn-ended hook and restore any notifier that existed before Computer Use was enabled.
• A disabled profile must not execute Computer Use code on later turn-completion events.
• Multiple Codex profiles/instances should either share one well-defined system-wide Computer Use service or use collision-free per-profile service identities/endpoints.
• Two copies with the same macOS bundle identifier should not cause sustained service or launchservicesd CPU activity.

Additional information

Likely lifecycle/identity problem (hypothesis)

Two independent bundle copies advertise the same CFBundleIdentifier=com.openai.sky.CUAService and the same product identity while living at different paths. The simultaneous launchservicesd spike suggests that duplicate bundle registration/resolution may be an amplifier, although a sample/trace would be needed to prove that mechanism.

Separately, the UI disable path appears to persist enabled=false but does not fully reconcile runtime state. At minimum it misses some combination of:

• terminating profile-owned service and MCP client PIDs;
• unregistering/releasing the active service bundle;
• removing/restoring the installer-owned turn-ended notifier;
• cleaning up stale helpers when an instance exits or changes plugin state;
• arbitrating ownership when another profile already runs the same service identity.

Suggested fix/validation

1. Give Computer Use an explicit lifecycle owner keyed by desktop instance/profile.
2. On disable, atomically prevent new turn hooks, drain active calls, terminate owned clients/service, and restore the previous notifier.
3. Make service startup singleton/reference-counted system-wide, or give each profile a unique service identity/socket so two copies cannot fight through LaunchServices.
4. On app startup, detect stale Computer Use PIDs/hooks whose owner profile has the plugin disabled.
5. Add a regression test with two distinct Codex homes:

• enable Computer Use in both;
• start both services;
• disable one profile;
• assert its hook and processes disappear;
• assert the remaining profile stays functional and idle;
• assert the disabled profile cannot relaunch Computer Use on turn-ended.

Related issues (overlapping components, but not the full dual-instance failure)

• #29157 — leaked SkyComputerUseClient turn-ended helpers.
• #30298 — disabled Computer Use restoring a notify hook/service on an older build.
• #28404 — Computer Use rewriting the user-owned notify hook.
• #38171 — MCP helper churn/high CPU in a different environment.

This report adds a reproducible dual-profile condition on current build 26.727.40816, simultaneous high CPU in two same-identifier service copies, and direct evidence that disabling one profile does not tear down its process tree or notifier.

All paths, profile identifiers, PIDs, turn payloads, and user-specific data have been redacted or normalized. No private configuration values are included.