[macOS] Computer Use cannot target a specific process when multiple apps share one bundle identifier

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

26.820.60940 (build 7119)

Bundled Computer Use plugin: 1.0.1000816

What subscription do you have?

ChatGPT subscription

What platform is your computer?

macOS 15.5 (24F74), Apple Silicon arm64

What issue are you seeing?

On macOS, Computer Use cannot select a specific application process or window when multiple running applications share the same bundle identifier.

I reproduced this with three independent Google Chrome processes, all registered as com.google.Chrome. One process owned the intended test window; the others did not.

The current app selector accepted each of these values:

• com.google.Chrome
• Google Chrome
• /Applications/Google Chrome.app

All three resolved to the same non-target Chrome state. Process-specific selector strings such as a numeric PID or pid:<PID> were rejected as invalid, and the visible window title was also not accepted as an app selector.

The result is that a caller can identify the correct window and owner PID through separate native observation, but cannot express that identity to Computer Use for the action. Selecting by bundle identifier can therefore observe or act on the wrong Chrome instance.

This affects Chrome and other macOS applications that can run multiple independent instances under one bundle identifier.

What steps can reproduce the bug?

1. Launch two or more independent Chrome processes on macOS, for example with distinct user-data directories.
2. Confirm that the processes have distinct PIDs but the same bundle identifier, com.google.Chrome.
3. Put a visibly distinct page or local test fixture in one instance.
4. Query Computer Use state using each supported string selector:
   • bundle identifier
   • display name
   • application path
5. Observe that the selectors resolve to the same Chrome instance rather than the specifically intended process.
6. Try to select the target using its PID, pid:<PID>, or its visible window title.
7. Observe that those selectors are rejected as invalid.

What is the expected behavior?

The macOS Computer Use API should support an exact structured target, for example:

{
  bundleIdentifier: "com.google.Chrome",
  ownerPid: 12345,   // optional exact process constraint
  windowId: 67890    // optional exact window constraint
}

Resolution should be conjunctive and fail closed:

• If all supplied fields match one live target, use that target.
• If the exact PID/window no longer exists or no longer belongs to that bundle, return a stale/not-found error.
• Never silently fall back from an exact process/window request to an arbitrary process sharing the bundle identifier.
• The app-access permission model should be able to authorize the corresponding level of specificity without weakening existing bundle-level controls.

Additional information

A local caller-side mitigation now refuses to act whenever the bundle identifier has more than one live registered owner. That prevents wrong-target input, but it does not restore the missing capability; legitimate control of the intended instance remains unavailable.

Static inspection of the installed signed Computer Use client shows macOS application/window identity concepts including NSRunningApplication, runningApplicationsWithBundleIdentifier:, ownerPID, and windowIDs. This suggests the native layer already has much of the identity information needed, although static strings alone do not establish its exact runtime call path.

This report is specifically about exact target selection. It is not a request to bypass foregrounding, Accessibility, Screen Recording, app-access approval, or any other safety control.

Start by locating the macOS Computer Use target-selection entry point and its handling of NSRunningApplication, runningApplicationsWithBundleIdentifier:, ownerPID, and windowIDs. Reproduce resolution with multiple processes sharing com.google.Chrome, then trace existing permission and stale-target behavior. Done means an exact process/window target is supported, mismatches fail closed, and regression coverage verifies no arbitrary fallback.