macOS Computer Use: allow PID/window selection for multiple instances of the same app

Summary

Please expose a supported way for Computer Use to select a specific running app instance by PID and/or window ID, including when multiple processes share the same executable path and bundle identifier.

I run two Godot editors on macOS, each editing a different game project, and use separate Codex CLI sessions for those projects. The current exposed cua API cannot distinguish the editor instances reliably.

Environment

• macOS on Apple Silicon
• Codex CLI sessions using the bundled unified Computer Use integration
• Installed integration observed: openai-bundled/unified-computer-use/26.901.41600
• Two Godot editor processes using the same Godot.app executable
• Shared bundle identifier: org.godotengine.godot
• Observed September 8, 2026

Reproduction

1. Launch two editors from the same Godot installation, each with a different project directory:

   "$GODOT_BIN" --editor --path /path/to/project-a
   "$GODOT_BIN" --editor --path /path/to/project-b
   

2. Confirm the OS reports two separate PIDs with different --path arguments.

3. In a Codex session with Computer Use available, call:

   await cua.getState();
   

4. Observe that the app inventory contains one running Godot entry with ID org.godotengine.godot, without per-process or per-window identifiers.

5. Select Godot:

   const editor = await cua.getApp("org.godotengine.godot");
   

6. The returned accessibility state identifies one project's editor window. There is no exposed PID/window selector to request the other editor instance.

Verified observations

• Two distinct editor processes were verified through the OS process list, with different project paths.
• Both use the same executable.
• cua.getState() returned one Godot app entry.
• cua.getApp("org.godotengine.godot") returned the first project's editor window in the observed call.
• The runtime-provided API documents getApp(app: string) with app display name, full app path, or bundle identifier. It exposes no PID or window selector.

This report concerns the supported API exposed to the agent. It does not claim that the underlying native implementation cannot identify processes or windows, nor that every selection always returns the same instance.

Expected behavior

• Enumerate running app instances/windows with enough identity to distinguish them: bundle identifier, PID, window ID, and window title.
• Allow an agent to select a specific instance/window through the supported API.
• Keep accessibility observations, screenshots, and input bound to the selected target.
• Return an explicit stale-target or ambiguous-target error if that instance exits or cannot be resolved, rather than silently switching to another process with the same bundle ID.

Illustrative API only:

const editor = await cua.getApp({ bundleId: "org.godotengine.godot", pid: targetPid });
// Or select a window from an enumerated list using a window ID.

Impact

A Codex CLI working in project B can receive project A's editor UI, with no supported way to select B. Naming the project in the prompt or supplying the app path does not provide a unique app-instance identity when both editors share that path and bundle ID.

This is useful even for one agent controlling one editor while both projects remain open; simultaneous input from multiple agents is not required to reproduce the limitation.

Related issues

• #20852 — broader request for parallel Computer Use sessions and explicit app/window ownership.
• #24301 — macOS screenshots capturing unrelated windows.
• #21668 — wrong macOS Space/window selection.
• #41323 — Windows-specific target-window capture and input request.

This request focuses specifically on distinguishing multiple running instances of the same macOS app in the exposed Computer Use API.

Start by locating the exposed Computer Use API entry points for cua.getState() and cua.getApp(), then trace how macOS app and window instances are enumerated and selected. Compare the behavior with the reported PID and window identity requirements; done means distinct same-bundle instances can be enumerated, selected, and reported as stale or ambiguous instead of silently switching targets.